|
锁定老帖子 主题：论面向组合子程序设计方法 之 微步毂纹生
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-08-07
失乐园：关于本文谈到的OO这个概念的一些初步界定。
http://forum.iteye.com/bloglist.php?userid=6423 |
| 返回顶楼 | |
|
发表时间：2005-08-07
引用 但是，有一点从OO的前驱PO那里开始到现在都没有变化，那就是，它们始终都是自顶向下的逐渐细化求精的方法论。 这一点肯定是有问题的，OO甚至PO都不限制是自顶向下还是自底向上的，用时髦的话说，OO和上下顶底的开发方式是"正交的"。 远的不说，这几年流行的XP,TDD之类的，是不是自底向上不好说，但必然算不上是自顶向下的。而且，即便是PO/结构化分析的年代，也就已经有了自顶向上和自底向下两套方法论，造出来的都是PO的东西。 |
| 返回顶楼 | |
|
发表时间：2005-08-07
ajoo 写道 失乐园：关于本文谈到的OO这个概念的一些初步界定。
http://forum.iteye.com/bloglist.php?userid=6423 嘿嘿，看了ajoo后面的第二篇，特别是看到interface的概念以及意义，深得我心，不敢说ajoo说全了，但至少把关键的东西说出来。 上次看到老庄对interface的质疑，但是质疑之后的辩述让我感觉他似乎没有完全理解interface的意义。 关于模扳，也有它不适用的地方，它最大的缺点就是强迫要求扩展点实现相同的签名，这种强迫有时候会带来一种无奈甚至似是而非的设计。不过，最近热得发火的AOP可以很好的与之互补。 AspectJ确实以一种更贴切的设计互补于OOP。 |
| 返回顶楼 | |
|
发表时间：2005-08-07
为什么DJ要将Event提出作为语法概念
庄表伟 写道 再来说一个软件开发与编程语言的伟大目标：“正交性”。是啊，正交自然是一个好东西，互不相干、互不影响的概念、功能，通过各种“自然、自由、方便”的组合，就能够千变万化，产生丰富的功能。很多语言在设计之初，就以追求正交性为目标，很多框架、系统，也有或多或少这方面的追求。在达不到正交性这样一个“设计目标中的制高点”之后，“松耦合”才被提出来、面向接口编程才被提出来、设计模式才被提出来......
不扯远了，说说我的看法吧，我认为，正交性这样的追求，在重新设计以前已经做过的系统时，或许还是可能的，而对于一个设计者了解不深的系统，正交性设计几乎是不可能的。而为了追求正交性，低耦合这样的目标，程序员们写下了大量的“解耦”代码，以大量的工作量，来换取别人“好优雅的设计啊”这样的评价。而事实上，在DJ语言的概念中，代码之间相互影响是一开始就被“语言级”地考虑的。我认为，问题并不在于通过设计与重构减少“相交”，而在于通过合理的机制，尽可能无遗漏的发现“各种相互影响的事实”。并且基于对于实际影响情况的分析，再来决定系统如何进行重构。 看起来颇有点针锋相对呀 
|
| 返回顶楼 | |
|
发表时间：2005-08-07
无论是继承还是多态， 实际上都是为组合服务的， 不了解这一点， 就是对OO的一知半解。
例: 解码器的主要构成部件是解码芯片，只要置换解码芯片，我们就可以获得不同的解码器，显而易见，这是一种组合关系。
class decode_chip
{
public void Decode();;
}
class decode_chip_1
{
public void Decode();;
}
class decode_chip_2
{
public void Decode();;
}
class Decoder
{
public decode_chip chip;
public class Decode();
{
chip.Decode();;
}
}
Decoder decoder = new Decoder();;
// 装配解码芯片
decoder.chip = new decode_chip_1();;
decoder.chip = new decode_chip_2();;
decoder.Decode();;
以上代码无法通过编译，虽然decode_chip、decode_chip_1、decode_chip_2的构造完全相同，但是Decoder只认识decode_chip，这种情况在现实世界中是无法想象的，完全按照规格制作的芯片却不能使用。 为了让芯片能够正常装配及工作，我们必须使用继承和多态。
class decode_chip
{
virtual public void Decode();;
}
class decode_chip_1 : decode_chip
{
override public void Decode();;
}
class decode_chip_2 : decode_chip
{
override public void Decode();;
}
|
| 返回顶楼 | |
|
发表时间：2005-08-08
charon 写道 引用 但是，有一点从OO的前驱PO那里开始到现在都没有变化，那就是，它们始终都是自顶向下的逐渐细化求精的方法论。 这一点肯定是有问题的，OO甚至PO都不限制是自顶向下还是自底向上的，用时髦的话说，OO和上下顶底的开发方式是"正交的"。 远的不说，这几年流行的XP,TDD之类的，是不是自底向上不好说，但必然算不上是自顶向下的。而且，即便是PO/结构化分析的年代，也就已经有了自顶向上和自底向下两套方法论，造出来的都是PO的东西。 我加了一篇补充，具体解释了一下“自顶向下”的内涵以及为什么tdd, xp仍然属于自顶向下。 http://forum.iteye.com/bloglist.php?userid=6423 |
| 返回顶楼 | |
|
发表时间：2005-08-08
庄表伟 写道 为什么DJ要将Event提出作为语法概念
庄表伟 写道 再来说一个软件开发与编程语言的伟大目标：“正交性”。是啊，正交自然是一个好东西，互不相干、互不影响的概念、功能，通过各种“自然、自由、方便”的组合，就能够千变万化，产生丰富的功能。很多语言在设计之初，就以追求正交性为目标，很多框架、系统，也有或多或少这方面的追求。在达不到正交性这样一个“设计目标中的制高点”之后，“松耦合”才被提出来、面向接口编程才被提出来、设计模式才被提出来......
不扯远了，说说我的看法吧，我认为，正交性这样的追求，在重新设计以前已经做过的系统时，或许还是可能的，而对于一个设计者了解不深的系统，正交性设计几乎是不可能的。而为了追求正交性，低耦合这样的目标，程序员们写下了大量的“解耦”代码，以大量的工作量，来换取别人“好优雅的设计啊”这样的评价。而事实上，在DJ语言的概念中，代码之间相互影响是一开始就被“语言级”地考虑的。我认为，问题并不在于通过设计与重构减少“相交”，而在于通过合理的机制，尽可能无遗漏的发现“各种相互影响的事实”。并且基于对于实际影响情况的分析，再来决定系统如何进行重构。 看起来颇有点针锋相对呀 为什么针锋相对？不明白。 
|
| 返回顶楼 | |
|
发表时间：2005-08-08
ajoo 写道 这种从分析需求，分解需求，分配责任，再分析子需求，分解子需求，在子模块内分配责任的方式，被我称为“自顶向下”。 这样说就妥当了。 因为你的这种定义和传统的说法是不同的。否则，先需求再分配，和顶底上下是无关的。至于子需求的分解，取决于策略的粒度。或者说，顶底上下的说法可以划分为战略上的和战术上的，现代的敏捷开发方式，在战略上是自底向上的。在有明确建模的重型迭代方法，则是自顶向下建模，自底向上演进实现的典型。而早期的瀑布方法，则自顶向下的含义更多一点，不过，即便是此时，用某些方法，比如OMT，也是所谓的"自底向上归纳，自顶向下分解"，需求的分析是自底向上的，而建模后的职责分解则是自顶向下的。 从建模实施的角度来看，在一个范围内所实施的是否是自顶向下的策略，取决于该区域内在具体实施之前或实施的相对靠前的阶段有没有出现一个可实现的全局(该区域内)模型。 |
| 返回顶楼 | |
|
发表时间：2005-08-08
ajoo 写道 庄表伟 写道 为什么DJ要将Event提出作为语法概念
庄表伟 写道 再来说一个软件开发与编程语言的伟大目标：“正交性”。是啊，正交自然是一个好东西，互不相干、互不影响的概念、功能，通过各种“自然、自由、方便”的组合，就能够千变万化，产生丰富的功能。很多语言在设计之初，就以追求正交性为目标，很多框架、系统，也有或多或少这方面的追求。在达不到正交性这样一个“设计目标中的制高点”之后，“松耦合”才被提出来、面向接口编程才被提出来、设计模式才被提出来......
不扯远了，说说我的看法吧，我认为，正交性这样的追求，在重新设计以前已经做过的系统时，或许还是可能的，而对于一个设计者了解不深的系统，正交性设计几乎是不可能的。而为了追求正交性，低耦合这样的目标，程序员们写下了大量的“解耦”代码，以大量的工作量，来换取别人“好优雅的设计啊”这样的评价。而事实上，在DJ语言的概念中，代码之间相互影响是一开始就被“语言级”地考虑的。我认为，问题并不在于通过设计与重构减少“相交”，而在于通过合理的机制，尽可能无遗漏的发现“各种相互影响的事实”。并且基于对于实际影响情况的分析，再来决定系统如何进行重构。 看起来颇有点针锋相对呀 为什么针锋相对？不明白。 我不认为以追求“正交性”为目标的“组合子”，是有价值的。 从根本上来说，“正交性”是一个伪目标。 |
| 返回顶楼 | |
|
发表时间：2005-08-08
老庄 写道 而为了追求正交性，低耦合这样的目标，程序员们写下了大量的“解耦”代码，以大量的工作量，来换取别人“好优雅的设计啊”这样的评价。
提醒老庄留意一个事实：真正提供了较好正交分解的系统，即便不看LISP，在JAVA世界里，例如Spring的IoC和AOP，也是不需要程序员为“解耦”这一目标编写额外代码的。实际上，如果说程序员需要为“解耦”而编写特殊的代码，那么就意味着他已经知道耦合的存在，那么这所谓的“正交”就已经是扯淡。后者，EJB者是。 |
| 返回顶楼 | |
