查看OO设计原则的源代码 OO设计原则 0

== 1 目的 ==

设计原则是基本的工具，应用这些规则可使代码更加灵活、更容易维护，更容易扩展

== 2 分类 ==

=== 2.1 SRP(单一职责) ===

The single responsibility principle

系统中的每一个对象都应该只有一个单独的职责，而所有对象所关注的就是自身职责的完成。

Every object in your system should have a single responsibility ,

and all the object s services should  be focused on carrying out that single responsibility .

每一个职责都是一个设计的变因，需求变化的时候，需求变化反映为类职责的变化。

当你系统里面的对象都只有一个变化的原因的时候，你就已经很好的遵循了SRP原则。

如果一个类承担的职责过多，就等于把这些职责耦合在了一起。一个职责的变化就可能削弱或者抑制

这个类其它职责的能力。这种设计会导致脆弱的设计。当变化发生的时候，设计会遭到意想不到的破坏。

SRP 让这个系统更容易管理维护，因为不是所有的问题都搅在一起。

内聚Cohesion 其实是SRP原则的另外一个名字.你写了高内聚的软件其实就是说你很好的应用了SRP原则。

怎么判断一个职责是不是一个对象的呢？你试着让这个对象自己来完成这个职责，比如：“书自己阅读内容”，

阅读的职责显然不是书自己的。

仅当变化发生时，变化的轴线才具有实际的意义，如果没有征兆，那么应用SRP或者任何其它的原则都是不明智的。

 
=== 2.2 DRY (不要重复代码) ===

Don't repeat yourself Principle

通过抽取公共部分放置在一个地方避免代码重复.


Avoid duplicate code by abstracting out things that are common and placing those thing in a single location .

DRY 很简单，但却是确保我们代码容易维护和复用的关键。

你尽力避免重复代码候实际上在做一件什么事情呢？是在确保每一个需求和功能在你的系统中只实现一次，否则就存在浪费！系统用例不存在交集，所以我们的代码更不应该重复，从这个角度看DRY可就不只是在说代码了。

DRY 关注的是系统内的信息和行为都放在一个单一的，明显的位置。就像你可以猜到正则表达式在.net中的位置一样，因为合理所以可以猜到。

DRY 原则：如何对系统职能进行良好的分割！职责清晰的界限一定程度上保证了代码的单一性。
 

=== 2.3 OCP (开闭原则) ===

Open-Close Principle

类应该对修改关闭，对扩展打开；

Classes should be open for extension ,and closed  for modification .

OCP 关注的是灵活性，改动是通过增加代码进行的，而不是改动现有的代码；

OCP的应用限定在可能会发生的变化上，通过创建抽象来隔离以后发生的同类变化

OCP原则传递出来这样一个思想：一旦你写出来了可以工作的代码，就要努力保证这段代码一直可以工作。这可以说是一个底线。稍微提高一点要求, 一旦我们的代码质量到了一个水平，我们要尽最大努力保证代码质量不回退。这样的要求使我们面对一个问题的时候不会使用凑活的方法来解决，或者说是放任自流的方式来解决一个问题；比如代码添加了无数对特定数据的处理，特化的代码越来越多，代码意图开始含混不清，开始退化。

OCP 背后的机制：封装和抽象；封闭是建立在抽象基础上的，使用抽象获得显示的封闭；

继承是OCP最简单的例子。除了子类化和方法重载我们还有一些更优雅的方法来实现比如组合；

怎样在不改变源代码（关闭修改）的情况下更改它的行为呢？答案就是抽象，OCP背后的机制就是抽象和多态

没有一个可以适应所有情况的贴切的模型！一定会有变化，不可能完全封闭.

对程序中的每一个部分都肆意的抽象不是一个好主意，正确的做法是开发人员仅仅对频繁变化的部分做出抽象。

拒绝不成熟的抽象和抽象本身一样重要。

OCP是OOD很多说法的核心，如果这个原则有效应用，我们就可以获更强的可维护性可重用 灵活性 健壮性

LSP是OCP成为可能的主要原则之一

 
=== 2.4 LSP（子类必须能够替换基类） ===

The Liskov substitution principle

子类必须能够替换基类。

Subtypes must be substitutable  for their base types.

LSP关注的是怎样良好的使用继承.

必须要清楚是使用一个Method还是要扩展它，但是绝对不是改变它。

LSP清晰的指出，OOD的IS-A关系是就行为方式而言，行为方式是可以进行合理假设的，是客户程序所依赖的。

LSP让我们得出一个重要的结论：一个模型如果孤立的看，并不具有真正意义的有效性。

模型的有效性只能通过它的客户程序来表现。必须根据设计的使用者做出的合理假设来审视它。

而假设是难以预测的，直到设计臭味出现的时候才处理它们。

对于LSP的违反也潜在的违反了OCP
 

=== 2.5 DIP(依赖倒置原则) ===

高层模块不应该依赖于底层模块 二者都应该依赖于抽象

抽象不应该依赖于细节 细节应该依赖于抽象

什么是高层模块？高层模块包含了应用程序中重要的策略选择和业务模型。

这些高层模块使其所在的应用程序区别于其它。

如果高层模块依赖于底层模块，那么在不同的上下文中重用高层模块就会变得十分困难。然而，

如果高层模块独立于底层模块，那么高层模块就可以非常容易的被重用。该原则就是框架设计的核心原则。

这里的倒置不仅仅是依赖关系的倒置也是接口所有权的倒置。应用了DIP我们会发现往往是客户拥有抽象的接口，

而服务者从这些抽象接口派生。

这就是着名的Hollywood原则:"Don't call us we'll call you."

底层模块实现了在高层模块声明并被高层模块调用的接口。

通过倒置我们创建了更灵活 更持久更容易改变的结构

DIP的简单的启发规则：依赖于抽象；这是一个简单的陈述，该规则建议不应该依赖于具体的类，

也就是说程序汇总所有的依赖都应该种植于抽象类或者接口。

如果一个类很稳定，那么依赖于它不会造成伤害。然而我们自己的具体类大多是不稳定的，

通过把他们隐藏在抽象接口后面可以隔离不稳定性。

依赖倒置可以应用于任何存在一个类向另一个类发送消息的地方

依赖倒置原则是实现许多面向对象技术多宣称的好处的基本底层机制，是面向对象的标志所在。


=== 2.6 ISP(接口隔离原则) ===

不应该强迫客户程序依赖它们不需要的使用的方法。

接口不是高内聚的，一个接口可以分成N组方法，那么这个接口就需要使用ISP处理一下。

接口的划分是由使用它的客户程序决定的，客户程序是分离的接口也应该是分离的。

一个接口中包含太多行为时候，导致它们的客户程序之间产生不正常的依赖关系，我们要做的就是分离接口，实现解耦。

应用了ISP之后，客户程序看到的是多个内聚的接口。


=== 2.7 One Rule, One Place ===

A very important implementation strategy to follow is to have only one place where you implement a rule. In other words, if you have a rule how to do things, only implement that once. This typically results in code with a greater number of smaller methods. The extra cost is minimal, but it eliminates duplication and often prevents many future problems. Duplication is bad not only because of the extra work in typing things multiple times, but because of the likelihood of something changing in the future and then forgetting to change it in all of the required places.

Although the draw method or Rectangle could directly call the drawLine method of whatever Drawing object the Shape has, I can improve the code by continuing to follow the one rule, one place strategy and have a drawLine method in Shape that calls the drawLine method of its Drawing object.

I am not a purist (at least not in most things), but if there is one place where I think it is important to always follow a rule, it is here. In the following example, I have a drawLine method in Shape because that describes my rule of drawing a line with Drawing. I do the same with drawCircle for circles. By following this strategy, I prepare myself for other derived objects that might need to draw lines and circles.


=== 2.8 Design By Contract ===

契约式设计(Design By Contract)把类和它的客户程序之间的关系看作正式的协议，描述双方的权利和义务。Bertrand Meyer把它称作构建面向对象软件系统方法的核心。

契约式设计的提出，主要基于软件可靠性方面的考虑。可靠性包括正确性和健壮性，正确性指软件按照需求规格执行的能力，健壮性指软件对需求规格中未声明状况的处理能力。健壮性主要与异常处理机制相关
。正确性一方面包括对象元素内部运行的正确性，另一个重要方面是与其它对象元素交互时的正确性。客户程序(Client) methodA调用提供者(Provider)
methodB时，先需要按照methodB的要求准备好参数，这是methodA的责任；然后methodB需要按照功能规格正确的进行处理，将结果返回给调用者methodA，这是methodB的责任，也是methodA应得的利益。契约的双方都有自己的责任和利益，在Building bug-free O-O software: An introduction to Design by Contract中，Bertrand Meyer给出了示例，从实际生活中的契约引申到对象元素间的契约。契约式设计就是要求提供一套机制，在客户程序与提供者之间明确的声明双方的职责与权利，即契约，并能够对这些契约进行验证
(未完)

http://www.zhanghq.net/archives/229



参考资料：

http://my.oschina.net/ITBoy/blog/17622

http://www.blogjava.net/chunkyo/archive/2007/01/21/95093.html

http://hi.baidu.com/%CA%F3%C0%AD/blog/item/2375e7d3055998dda8ec9a40.html

http://www.zhanghq.net/archives/229