CSDN博客

img cl2001928

面向对象设计的新视角

发表于2004/10/25 10:35:00  782人阅读

Alan Shalloway是Net Objectives的创建者和总裁,自1981年起,为工业界提供面向对象和软件开发的指导和培训,如Attachmate, Avaya, Boeing, IBM, Microsoft, Phillips Medical Systems, Price Waterhouse Coopers, QWest等,Alan的研究范围包括:design patterns, Java, C++, XML, XP和敏捷软件开发。他的书"Design Patterns Explained: A New Perspective on Object-Oriented Design"(中译本《设计模式精解》即将发行,由透明(gigix)翻译)被《设计模式》的作者John Vlissides称为最好的设计模式入门书籍。Alan曾在MIT获得计算机科学硕士学位。以下是交流实录。由gigix翻译。
模式矩阵
  gigix:最近好象你快变成一个XPer了,是不是?最近你最喜欢的方法学是什么? 
  shalloway:SCRUM也有很多精彩的思想。 
  gigix:那你还喜欢模式矩阵吗? 
  shalloway:我正在重新写模式矩阵,我打算再把它扩展一些。 
  gigix:你现在怎么看待模式矩阵呢?使用模式矩阵来做预先设计,这样的方法好吗?   shalloway:模式矩阵是学习模式的好工具,我想它的主要优点是能够用来进行模式之间的比较和对比。对模式矩阵的研究仍在进行之中。另外,我认为预先的设计和渐进的设计都是有必要的。当你对问题领域非常熟悉时,你可以在预先的设计中留下扩展的空间。但是,扩展的空间不能留得太多,我们不想实现不需要的东西。另一方面,我很赞赏XP中“简单”的原则。除非需要,否则不要实现任何东西。我的原则是: 
  1、测试优先(并保证测试的自动化); 
  2、切实遵循松耦合、高内聚、无冗余的原则,用代码表明自己的意图。 
  gigix:我觉得模式矩阵和敏捷方法是冲突的,是吗? 
  shalloway:为什么你会这么想呢? 
  gigix:因为它提倡使用模式预先做设计。 
  shalloway:让我来解释一下:也许XP的确说过“不要预先做任何设计”,但是其他敏捷方法通常不会这样。敏捷方法的基础是迭代式开发、每天至少构建一次、经常听取客户的反馈、重视人的价值、自动化测试和及时的重构。“不做预先设计”和“成对编程”是XP的实践,但不是所有敏捷方法的实践。我不相信只要使用模式就会造成过分设计。但是,也不要想当然地去使用模式。只有当你看到问题领域的状况和某个模式完全符合时,才能应用这个模式。我经常听见人们问:“我的Strategies在哪里?”这就是误用了模式:当你手上只有锤子时,你就想把所有的问题都当成钉子。模式实际上是事物之间的关联。比如说,Strategy模式就描述了“可能使用不同规则的事物”之间的关联。模式教给我们一种看待问题领域的新视角。 
设计模式
  xlp223:你认为新手应该从哪些模式开始学习呢? 
  shalloway:入门的模式:Strategy、Abstract Factory、Composite、Bridge、Factory Method、Proxy、Decorator、Observer、Iterator、Adaptor、Facade和Template Method。就算你不用它们做设计,这些模式包含的概念也是开发者需要知道的。   gigix:您看了最近Joshua Kerievsky在SDMagazine上发表的文章吗?他认为模式很容易造成过分工程。 
  shalloway:只有当你用错了模式的时候,它们才会造成过分工程。可惜,大半的人都会用错。不过,正如我经常说的--模式是用来描述问题领域中事物的关联的。只要我们不想当然地虚构一些不存在的东西,模式就不会伤害我们。   crystal_y:大量的领域知识→倾向于提前设计→可能过分工程,到什么时候算完?要知道“什么时候该停”,我们需要什么呢?经验吗?更多的领域知识吗?更多的计算机科学知识吗?   shalloway:在预先做设计的时候,只需要表现出问题领域的概念就可以了,不要操心特定的实现方法。敏捷方法会强迫你这样做,因为它要求你在一定的时间内实现一定数量的功能。   crystal_y:领域知识可以帮助我们更好地理解问题,而模式则可以帮助我们理解问题的抽象。敏捷方法则可以帮助我们更快地得到反馈,以改进我们的理解。对吗?   shalloway:实际上,模式会从分析、设计和实现的角度来告诉我们问题。比如说,在分析阶段,我可能会发现我有几种不同的文档,需要支持不同的输出设备。所以,我看到系统中有文本、图片……它们使用激光打印机、绘图仪、点阵等等作为输出设备。这正是Bridge模式的场景。所以,我可以用一个抽象(不同的文档类型)来定义问题领域,然后给它以不同的实现(点阵、绘图仪等等)。现在我不必担心如何实现,因为我对Bridge模式很有把握。要求更快得到反馈则使你不得不对开发过程进行调整,因为你不能再等待完整的需求,也不能再希望做完整的系统设计,也不能先做完所有的编码工作再测试。   xlp223:关于模式的好处,您已经谈了很多。我想知道,您认为设计模式有什么缺陷? 
  shalloway:我想设计模式最大的问题就是“设计”这个词,它让人们会觉得模式就是关于设计的。实际上,模式并不仅仅限于设计阶段,之所以它会叫“设计模式”,是因为Gamma他们研究的主要是可复用的设计方案。在分析阶段和实现阶段,都有相关的模式。
面向对象设计
  zergo:您能告诉我设计对象时的一些原则吗? 
  shalloway:对象是负有责任的事物。它们对自己负责。你通过接口来与它们交谈。你只管它们"做什么",而不用管它们"怎么做"。
  yhufo:类的接口总是比较难设计,您能告诉我一些接口设计的技巧吗? 
  shalloway:当你设计接口时,不要只想到手上的情况,还要想到现在的情况可能发生哪些变化,这是很重要的。但是,为了保持开发过程的敏捷,在你考虑其他情况时,不要对接口做不必要的扩展。不过,有时候通过展望未来的需求,你可以得到一个比较具有普遍意义的解决方案。 
  Charity_Zhou:您怎么看待软件设计中复用性和复杂性的关系? 
  shalloway:在面向对象设计中有一种不好的倾向:从一开始就强迫可复用的代码。这本来不是一种好的想法,但我们却经常这样做。我们设计超类的时候很注意复用性,然后在需要变化的时候就在子类中覆盖超类的方法。问题是,这常常会导致不相关的概念之间产生耦合。比如说吧,假设你要创建一个销售定单系统,你用超类来表现相似的概念(税费、运费等等"费用"),然后在子类中来区分它们。结果,你就在税费和运费之间造成了耦合。一段时间里,这不成问题,但是它终究会出问题。它会使你的系统难以理解。在编程的时候,我们需要注意松耦合(以避免副作用)和高内聚(为了让代码清楚易读),还要避免冗余(出于效率的考量)。我们能够把握自己这边出现的复杂性--把它们藏在接口或者抽象类的后面。而对于问题领域出现的事物,我们就应该问问自己:它是做某一件事的特定方法吗?还是做某一类事情的普遍方法?《设计模式》这本书告诉了我们如何寻找可能发生变化的东西,如何封装变化点:找到普遍的概念,为普遍概念定义接口,让客户调用该接口;对于特定的方法,实现该普遍接口。   gigix:我认为面向对象设计的原则(例如开放-封闭原则)比具体的模式更重要,是吗? 
  shalloway:我同意。模式只是一种具体的解决方案。不过,XP认为:根本不要管OCP(开放-封闭原则)。 
  gigix:啊?如果不遵循OCP,又怎么保证代码的质量呢? 
  shalloway:你根本不可能写出永不修改的代码,而这正是OCP的目标。但是,请问问你自己,为什么要避免修改代码呢?当然,理由会有很多。比如说,好多代码都很脆弱--如果修改了一个地方,就会破坏另一个地方。但是,如果你一开始就想着降低代码的耦合程度,那么修改就不会造成副作用。你可能又会找出另一个理由:如果我修改了代码,就必须重新做测试。但是,如果你预先准备好了自动化测试,那么系统测试的代价也不会很高昂。软件开发者中流传着一个说法:我们用了大量的时间来修复错误。是吗?有多少人这样想?想想你最难的问题,最难的错误。现在,想想你用了多少时间来找到代码中的错误?如果代码结构良好,你能节约多少时间?如果代码中保持松耦合,又能节约多少时间?不管怎么说,大半的时间都不是耗在修复上面。错误的修复耗费的时间是比较少的,发现错误所需的时间要多得多。 
  gigix:同意。 
  shalloway:在80年代,我把一半的编码时间(也就是全部时间的10%)用在了我写的一个系统上。那时我的编码技巧还很不成熟,代码里有很多耦合,内聚程度也不好。这是一次很好的体验。 
  gigix:那么它肯定很难维护。   shalloway:对。如果没有强内聚、耦合又紧密、测试又少,那么系统的确很难维护。 
  gigix:我还有个问题。在OOD中,哪些原则是最重要的? 
  shalloway:我无法说哪些原则是“最重要”的,但是我可以列举出一些重要的原则。你应该把对象看成定义良好的责任;对象应该对自己负责;封装是某种形式的隐藏:隐藏数据、实现或者是类;让事物之间的耦合明确化(松耦合);每个方法做一件事、也只做一件事;类只包含相关的方法;尽量避免冗余。 
  outmyth:我要怎么达到“低耦合”这个目标呢? 
  shalloway:“低耦合”意味着要这样定义你的接口:让调用对象正好可以送出服务对象需要的所有信息。私有数据和私有方法可能会有帮助。 
  crystal_y:抽象、共同点/变化点分析,这些是得到松耦合的核心吗? 
  shalloway:这些东西可以帮助你以一种更好的方式来看待问题领域。如果你这样编程,那么要处理的东西就少得多了。设计接口的时候只需要考虑如何表现变化事物之间的共同点就行了。 
  agilemind:粒度适当的、松耦合的设计模式真正的价值是什么,您能告诉我吗? 
  shalloway:松耦合的事物可以发生变化而不引起副作用,也不至于造成很多代码修改。 
敏捷方法和XP 
  leohoo:敏捷方法和XP之间有什么区别,您能告诉我吗? 
  shalloway:XP是一种敏捷过程。它有四种价值:勇气、简单、诚实和交流。它有12条实践。它是进行敏捷开发的一种方法。当然,也有其他的敏捷方法,SCRUM就很不错。就连RUP,你也可以按照敏捷的方法来使用它。敏捷是一种方法,它认为你不可能一开始就知道所有的需求,起码在大多数的项目中是这样。如果你能够提前知道所有的需求,那么你就不需要敏捷方法。   simaetin:"诚实"?还是"反馈"? 
  shalloway:"诚实"是XP的一种价值,"反馈"则是你需要得到的东西。所有的敏捷方法都要求尽量听取用户的反馈,所以你应该少做早期准备工作。早期准备越少,你就能越快地给用户看一些原型产品,并得到反馈。当然,每个人都应该根据自己的需要而取舍XP的价值。就我个人而言,我不一定会从XP开始。我会从这些实践开始:预先准备自动化测试、每天构建、迭代。也许SCRUM会更容易实现。不过,如果你喜欢成对编程--那就去做吧。我觉得成对编程很不错,但是也有些人不喜欢它,这多半是因为美国人崇尚西部牛仔式的个人英雄主义。   flyingsaucer:有人说XP适用于有经验的开发者,而不适合新手,您怎么看呢? 
  shalloway:我想,在XP的项目中的确需要一些高级开发者。但是,任何没有高级开发者的项目都肯定会遇到麻烦。如果没有很好的编码技巧,持续的重构也会让人觉得不舒服,但是,如果使用XP,起码你只需要让一半的开发者知道自己要做的事,而另一半的人可以先坐在一边学习。 其他技术
  flyingsaucer:Shalloway先生,您对AOP(Aspect-Oriented-Programming)怎么看?它未来的发展会如何?   shalloway:我没有研究过。不过,一些我很尊敬的人说它很不错。如果有时间,我会多学习一些的。 
  sinba72:您能给我推荐一本好的UML书吗?我是个UML的初学者。 
  shalloway:Martin Fowler的UML Distilled不错。 
  pplove.shao:您能告诉我一些OR映射的模式吗? 
  shalloway:我没研究过OR映射,不过我可以告诉你到哪儿去找这些资料。Scott Ambler已经做了很多这方面的研究,但是还没有完成,你可以到www.ronin-intl.com去看看。另外,他也够有名了,在Yahoo!上就能搜索到他。   cajan2:您能告诉我如何在实时系统中应用模式吗? 
  shalloway:对于实时系统,我没有多少经验。不过,关于这个主题,最好的书就是Schmidt的Pattern Oriented Software Architecture Volume 2。 
  banq:在EJB中有多少设计模式? 
  shalloway:有一本关于EJB模式的好书:EJB Design Patterns。可惜据我所知,这本书只有英文版本。EJB之所以很有用,是因为通过EJB我们可以把特定的功能放进一个对象里面,然后再也不必担心对象的生存周期、存储之类的事情。即使不使用EJB,这些设计思想也是很重要的。
 
告别
  shalloway:有件事我得声明一下:我参加今天的交流,不光是为了宣传我们的书,还因为我有可能到中国来做培训。我希望有人能帮助我安排到中国的行程。如果你能够帮忙,请和我联系:alshall@netobjectives.com。   gigix:欢迎来中国。 
  shalloway:夜已经很深了。很高兴今天和大家交流,我希望过几个月能再有这样的活动。再见,各位。感谢UMLChina主办今天的交流。感谢所有人的参与。   cajan2:Shalloway先生,很高兴今天能和您交流。再见。 
注: 
  模式矩阵(Pattern Matrix)是Alan Shalloway在Design Patterns Explained中提出的一种分析、设计方法。   XP中的价值的确是"反馈(feedback)"而非"诚实(honesty)",Shalloway先生可能记忆有误。   用成对编程的方法,初级开发者可以向同组的高级开发者学习,并尽量作出自己的贡献。
阅读全文
0 0

相关文章推荐

img
取 消
img