视角的力量--再说OO设计原则

       规约视角，对象是一组可以被其它对象或对象自己调用的方法（也就是行为，怎么使用软件?）；对象是有责任的我只需要关注对象的公共接口-这是我要求对象完成某些工作的交流渠道。只要对象的接口告诉我们它可以完成某项职责，不关注对象是怎样运行的。关注动机而非实现，是基本的OO设计原则，将实现隐藏在接口之后实际上是将对象的实现与它们的对象解耦了。

      实现视角，对象是代码和数据，以及它们之间的计算交互(软件怎么履行自己的责任?)；走到这里我们才开始讨论实现细节。

      总结一下，从Martin Fowler的三个视角来看对象：

在概念层次上，对象是一组责任

规约层次上，对象是一组可以被其他对象或者对象自己调用的方法

在实现层次上对象是代码和数据，以及它们的计算交互

到这里我们需要对OO基本原则做一个再思考了：

        从概念层到规约层我们的思考成果都是抽象的，他们是一个个抽象的概念，是一个个的行为；我们在概念层是对象的责任清晰化，在规约层我们看拥有不同责任的对象之间是怎样协作的。协作方式就是一种对象与对象之间的契约。对象的责任怎么划分？对象应该对自己负责，对象的责任应该尽量单一，这就是SRP原则。规约层我们定义的是对象间的交互契约，也就是接口，关注接口而非实现，我们做到了。

       概念层是最稳定的，规约层次之，实现是最不稳定的。所以高层模块不应该依赖低层模块，两者都应该依赖于抽象。细节应该依赖于抽象，这就是DIP原则。这个原则隐含的意思是：对象之间只在概念层次存在耦合，在实现层次不能耦合！

       我们定义的所有交互都是使用基类，那如果实现的时候某一个子类不能完全代替基类呢？那是不是所有的交互契约都出现问题了？一个从基类派生的子类应该支持基类的所有行为，子类必能替换基类，这就是LSP原则。

        可以看出对象的责任和交互被尽早的定义出来，这个过程中我们没有考虑具体对象在什么时期创建，映射到我们的设计过程中，创建型设计模式的应用往往是在设计的后期。

       结论：

附： Martin Fowler著作 《UML Distilled》提到三种视角（perspective）的段落：
 

Following the lead of Steve Cook and John Daniels (1994), I say that there are three perspectives you can use in drawing class diagrams- or indeed any model, but this breakdown is most noticeable in connection with class diagrams.

• Conceptual. 
  If you take the conceptual perspective, you draw a diagram that represents the concepts in the domain under study. These concepts will naturally relate to the classes that implement them, but there is often no direct mapping. Indeed, a conceptual model should be drawn with little or no regard for the software that might implement it, so it can be considered language-independent. (Cook and Daniels call this the essential perspective.)
• Specification. 
  Now we are looking at software, but we are looking at the interfaces of the software, not the implementation. Object-oriented development puts a great emphasis on the difference between interface and implementation, but this is often overlooked in practice because the notion of class in an OO language combines both interface and implementation. This is a shame, because the key to effective OO programming is to program to a class's interface rather than to its implementation. There is a good discussion of this in the first chapter of Gamma, Helm, Johnson, and Vlissides (1995). You often hear the word "type" used to talk about an interface of a class; a type can have many classes that implement it, and a class can implement many types.
• Implementation. 
  In this view, we really do have classes and we are laying the implementation bare. This is probably the perspective used most often, but in many ways the specification perspective is often a better one to take.

Understanding perspective is crucial to both drawing and reading class diagrams. Unfortunately, the lines between the perspectives are not sharp, and most modelers do not take care to get their perspective sorted out when they are drawing. Although I've found that this often does not matter too much between the conceptual perspective and the specification perspective, it is very important to separate the specification perspective and the implementation perspective.

As I talk about class diagrams further, I will stress how each element of the technique depends heavily on the perspective.

Perspective is not part of the formal UML, but I have found it extremely valuable when modeling and when reviewing models. The UML can be used with all three perspectives. By tagging classes with a stereotype (see page 79), you can provide an indication of the perspective. You mark classes with <> to show the implementation perspective, and with <> for the specification and conceptual perspectives.

《UML Distilled Second Edition A Brief Guide to the Standard Object Modeling Language》

Martin Fowler   Kendall Scott

Publisher: Addison Wesley

                Second Edition August 18, 1999

                ISBN: 0-201-65783-X, 224 pages