oop原则

关于OOP原则：
一些拾人牙慧的东西，不过很耐读，铭记在博客里：

概述：

OOP的方法论（高内聚、低耦合、易复用、易扩展、易维护）：
1. 代码重用（通常用继承和聚合实现）
2. 低耦合（模块与模块之间，类与类之间依赖程度低）
3. 高内聚（模块或类内部依赖程度高，负责处理相关的工作，避免“狗拿耗子”）
4. 易扩充（在不改变原有代码，或改变很小的情况下增加功能）
5. 易维护（代码结构清晰，容易管理和修改代码）

一 OCP（Open-Closed Principle） 开放－封闭原则
软件实体应该扩展开放、修改封闭：
1. “对于扩展是开放的” (Open for extension)。这意味着模块的行为是可以扩展的，当应用的需求改变时，我们可以对模块进行扩展，使其具有满足那些改变的新行为，换句话说，我们可以改变模块的功能。
2. “对于更改是封闭的” (Closed for modification)。对模块行为进行扩展时，不必改动模块的源代码或者二进制代码，模块的二进制可执行版本，无论是可链接的库、DLL或JAVA 的.jar文件，都无需改动。
实现：合理划分构件，一种可变性不应当散落在代码的很多角落里，而应当被封装到一个对象里；一种可变性不应当和另一个可变性混合在一起。

二 DIP(Dependency-Inversion Principles)依赖倒置原则
在传统的结构化编程中，最上层的模块通常都要依赖下面的子模块来实现，也称为高层依赖低层! DIP原则就是要逆转这种依赖关系，让高层模块不要依赖低层模块。
第1点：高层模块不依赖底层模块，两者都依赖抽象。
第2点：抽象不应该依赖于细节，细节应该依赖于抽象。
每个较高层次都为它所需要的服务声明一个抽象接口,较低的层次实现这些抽象接口,每个高层类都通过该抽象接口使用下一层的服务,接口属于高层,低层要实现高层的接口,因此现在是低层依赖于高层是依赖关系倒置和接口所有权的倒置。
实现：应该通过抽象耦合的方式，使具体类最大可能的仅和其抽象类（接口）发生耦合；程式在需要引用一个对象时,应当尽可能的使用抽象类型作为变量的静态类型,这就是针对接口编程的含义。

三 LSP(Liskov Substitution Principle) 替换原则
继承思想的基础。“只有当衍生类能够替换掉基类，软件单位的功能不会受到影响时，基类才真正被复用，而衍生类也才能够在基类的基础上增加新的行为。

四 ISP（Interface Insolation Principle）接口隔离原则
接口功能单一，避免接口污染。
一个接口代表一个角色，不应当将不同的角色都交给一个接口。没有关系的接口合并在一起，形成一个臃肿的大接口，这是对角色和接口的污染----角色隔离原则。
将接口理解成为侠义的java接口，这样一来，接口隔离原则讲的就是为同一个角色提供宽、窄不同的接口，以对付不同的客户端。这种办法在服务行业中叫做定制服务---定制服务。
“不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。”这个说得很明白了，再通俗点说，不要强迫客户使用它们不用的方法，如果强迫用户使用它们不使用的方法，那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。
实现：一个类对另外一个类的依赖性应当是建立在最小的接口上的。使用多个专门的接口比使用单一的总接口要好。
（动机：当我们设计应用程序的时候，如果一个模块包含多个子模块，那么我们应该小心对该模块做出抽象。设想该模块由一个类实现，我们可以把系统抽象成一个 接口。但 是当我们想要添加一个新的模块扩展程序时，如果要添加的模块只包含原系统中的一些子模块，那么就会强迫我们实现接口中的所有方法，并且还要编写一些哑方 法。这样的接口被称为胖接口或者叫被污染的接口，使用这样的接口将会给系统引入一些不正确的行为。）

五 SRP(Single Resposibility Principle) 单一职责原则
就一个类而言，应该仅有一个引起他变化的原因。 假如一个类的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会抑止这个类完成其他职责的能力。
单一职责原则的好处：
第一、有助于我们分析和编码的思路的清晰。（当你的代码里有了三层或以上的if语句或for语句的嵌套的时候，你不要跟我说，你已经把问题分析得很清楚了。多层嵌套的if或for语句只能说明你还没有把问题分析清楚。）
第二、使我们的编码、测试和维护变得简单。
第三、将一个个复杂的问题简单化以后，易于代码的重用。（当你的代码的多个功能搅和在一起的时候，你是没办法考虑代码的重用的，因为你的每一处代码都有不同。）
第四、易于系统的扩展

与接口隔离原则（ISP）的比较：
相同点：接口尽量细化，同时接口中的方法尽量少。
不同点：审视角度是不相同的，单一职责要求的是类和接口职责单一，注重的是职责，这是业务逻辑上的划分，而接口隔离原则要求接口的方法尽量少。（例如：一 个接口的职责可能包含10个方法，这10个方法都放在一个接口中，并且提供给多个模块访问，各个模块按照规定的权限来访问，在系统外通过文档约束“不使用 的方法不要访问”，按照单一职责原则是允许的，按照接口隔离原则是不允许的，因为它要求“尽量使用多个专门的接口”。专门的接口指什么？就是指提供给每个 模块都应该是单一接口，提供给几个模块就应该有几个接口，而不是建立一个庞大的臃肿的接口，容纳所有的客户端访问。）

六 LoD （Law of Demeter）迪米特法则
即最少知识原则。一个对象应当对其他对象有尽可能少的了解。只和最直接的类交互，对第三方可以通过转达交互，从而减少对象间的耦合性。

七 CARP（Composite/Aggregate Reuse Principle）合成/聚合复用原则
就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到复用已有功能的目的。简而言之就是：要尽量使用合成/聚合，尽量不要使用继承。
聚合：用来表示“拥有”关系或者整体和部分的关系。
合成：用来表示一种强得多的“拥有”关系。在一个合成里，部分和整体的生命周期是一样的。一个合成的新对象完全拥有对其组成部分的支配权，包括它们的创建和泯灭等。
合成/聚合复用：
优点:
* 新对象存取成分对象的唯一方法是通过成分对象的接口。
* 这种复用是黑箱复用，因为成分对象的内部细节是新对象所看不见的。
* 这种复用支持包装。
* 这种复用所需的依赖较少。
* 每一个新的类可以将焦点集中在一个任务上。
* 这种复用可以在运行时间内动态进行，新对象可以动态的引用与成分对象类型相同的对象。
缺点:
* 系统中会有比较多的对象需要管理。

通过继承的复用：
合成/聚合作为复用手段可以应用到几乎任何环境中去，而继承只能在有限的环境中使用。尽管继承是一种非常重要的复用手段，但应当首先考虑合成/聚合，而不是继承。

优点：
* 新的实现较为容易，因为超类的大部分功能可以通过继承的关系自动进入子类。
* 修改和扩展继承而来的实现较为容易。

缺点：
* 继承复用破坏包装，因为继承将超类的实现细节暴露给子类。由于超类的内部细节常常是对于子类透明的，所以这种复用是透明的复用，又称“白箱”复用。
* 如果超类发生改变，那么子类的实现也不得不发生改变。
* 从超类继承而来的实现是静态的，不可能在运行时间内发生改变，没有足够的灵活性。

在对违反里氏代换原则的设计进行重构时，有两种方法：一是加入一个抽象超类；二是将继承改为合成/聚合的关系。

“Is-A”代表一个类是另外一个类的一种，“Has-A”代表一个类是另一个类的一个角色，而不是另一个类的特殊种类。对于"Is-A"应该考虑使用继承，而"Has-A"使用合成/聚合。



备注：

设计模式和设计原则的关系就像是三十六计与孙子兵法的关系。前者是具体的人们总结的经验，这些经验体现着原则；后者是更一般的更抽象的更普遍的指导原则。 抓住可维护性和可复用性这两只同时在奔跑的兔子的方法是：支持可维护性的复用（在保持甚至提高系统的可维护性的同时，实现系统的复用）。

转载于：http://2005713.blog.51cto.com/1995713/542856