[ZT] 面向对象设计的新视角

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翻译。

摘了其中一段

全篇见 http://tech.ccidnet.com/pub/disp/Article?columnID=292&articleID=24346&pageNO=2

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：松耦合的事物可以发生变化而不引起副作用，也不至于造成很多代码修改。