ooD和设计模式的层次

本文转载地址：http://www.cnblogs.com/HQFZ/p/4630808.html

基础的面相对象原则

1. 封装，继承，多态
2. 当然，还有一些与之相关的一些原则，例如：抽象，关联，聚合，组合。

熟悉的SOILD（类层次的设计原则）

面向对象设计原则科学界定最常见派生方法构建健壮且灵活的系统
而SOLID原则又被证明是解决无法被基本的面向对象原则捕获的众多 OO 设计问题的最佳工具。
1.单一责任原则
类修改的原因（理由或动机）应该只有一个
2.开放封闭原则
软件实体（类，模块，函数）应该是可以扩展的，但是不能被修改
3.里氏替换原则
子类型必须能够替换掉他们的基类型
4.依赖倒置原则
高层模块不应该依赖于底层模块，两者都应该依赖抽象模块
抽象不应该依赖细节，细节应该依赖抽象
5.接口分离原则
不应该强迫客户依赖于他们不需要的方法，借口属于客户，不属于所在的类层次

包的设计原则

随着应用程序的规模和复杂度的增加，需要在更高的层次对它们进行组织。类对于小型应用程序来说事非常方便的组织单元，但是对于大型应用程序来 说，如果仅仅使用类作为唯一的组织单元，就会显得粒度过细。因此，就需要比类“大”的“东西”来辅助大型应用程序的组织。这个“东西”就是包 （package）。
本节描述了6个原则。前3个原则关注包的内聚性，这些原则能够指导我们如何把类划分到包中。后3个原则关注包的耦合性，这些原则帮助我们确定包之间的相互关系。

包的内聚性原则（粒度）：
重用-发布等价原则 共同重用原则 共同封闭原则
解释：
这3个关于包的内聚性原则，可以帮助开发者决定如何把类划分到包中。这些原则依赖于这样的事实：至少已经存在一些类，并且它们之间的相互关系也已经确定。因此，这些原则是根据“自底向上”的观点对类进行划分的。

包的耦合性原则（稳定性）：
无环依赖原则 稳定依赖原则 稳定抽象原则
解释：
这3个包的耦合性原则，用来处理包之间的关系。这里，我们会再次碰到可开发性与逻辑设计之间的冲突力（tension）。来自技术和行政方面的作用力都会影响到包的组织结构，并且这种作用力还是易变的

设计模式

创建类型：
1.抽象工厂（Abstact Factory）
2.建造者(Builder Pattern)
3.工厂方法(Factory Method pattern)
4.原型(Prototype pattern)
5.单例模式(Singleton pattern)

结构类型：
适配器(Adapter pattern)
桥接(Bridge pattern)
组合(Composite pattern)
装饰(Decorator pattern)
外观(Façade pattern)
享元(Flyweight pattern)
代理(Proxy pattern)

行为类型：
职责链(Chain-of-responsibility pattern)
命令(Command pattern)
解释器(Interpreter pattern)
迭代器(Iterator pattern)
中介者(Mediator pattern)
备忘录(Memento pattern)
观察者(Observer pattern)
状态(State pattern)
策略(Strategy pattern)
模板方法(Template method pattern)
观察者(Visitor)

工厂方法(Factory Method pattern)
【学习难度：★★☆☆☆，使用频率：★★★★★】
定义：定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法是一个类的实例化延迟到其子类。

抽象工厂（Abstact Factory）
【学习难度：★★★★☆，使用频率：★★★★★】
翻译：为创建一组相关或相互依赖的对象提供一个接口，而且无需指定它们的具体类。

单例模式(Singleton pattern)
【学习难度：★☆☆☆☆，使用频率：★★★★☆】
翻译：确保一个类只有一个实例，并提供一个全局访问点来访问这个唯一实例。

建造者(Builder Pattern)
【学习难度：★★★★☆，使用频率：★★☆☆☆】
翻译：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

原型模式（Prototype Pattern）
【学习难度：★★★☆☆，使用频率：★★★☆☆】
翻译：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。

补充一个不属于23经典模式的常用模式：

简单工厂模式(Simplified version of Factory Method)
【学习难度：★★☆☆☆，使用频率：★★★☆☆】
翻译：
1.简单工厂模式创建对象不暴露具体初始化对象的逻辑（一般通过一个表示具体类输入参数，又工厂自行创建对象），且客户端是引用的新创建对象的接口（或者基类而不不是具体的子类）。
2.简单工厂模式的实质是由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类（这些产品类继承自一个父类或接口）的实例。

适配器模式（Adapter Pattern）
【学习难度：★★☆☆☆，使用频率：★★★★☆】
翻译：将一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。

桥接模式（Bridge Pattern）
【学习难度：★★★☆☆，使用频率：★★★☆☆】
翻译：将抽象和实现解耦，使得两者可以独立的变化。

组合模式（Composite Pattern）
【学习难度：★★★☆☆，使用频率：★★★★☆】
翻译：将对象组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。

装饰模式（Decorator Pattern）
【学习难度：★★★☆☆，使用频率：★★★☆☆】
翻译：动态地给一个对象添加一些额外的职责。就增加功能来说，装饰模式相比生成子类更为灵活。

外观模式（Facade Pattern）
【学习难度：★☆☆☆☆，使用频率：★★★★★】
翻译：要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供了一个高层次的接口，使得子系统更容易使用。

享元模式（Flyweight Pattern）
【学习难度：★★★★☆，使用频率：★☆☆☆☆】
翻译：使用共享对象可有效地支持大量的细粒度对象。

代理模式（Proxy pattern）
【学习难度：★★★☆☆，使用频率：★★★★☆】
翻译：为其他对象提供一种代理以控制对这个对象的访问。

职责链模式（Chain of Responsibility Pattern）
学习难度：★★★☆☆，使用频率：★★☆☆☆】
翻译：使多个对象有机会处理请求，从而避免了请求的发送者和接收者之间的耦合关系 。将这些对象连成一个链，并沿着这条链传递请求，知道有对象处理它为止。

命令模式（Command Pattern）
【学习难度：★★★☆☆，使用频率：★★★★☆】
翻译：将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。

解释器模式（Interpreter Pattern）
【学习难度：★★★★★，使用频率：★☆☆☆☆】
翻译：给定一门语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。

迭代器模式（Iterator Pattern）
【学习难度：★★★☆☆，使用频率：★★★★★】
翻译：它提供一种方法访问一个容器对象中各个元素，而又不需要暴露该对象的内部细节。

中介者模式(Mediator Pattern)
【学习难度：★★★☆☆，使用频率：★★☆☆☆】
翻译：用一个中介对象封装一系列的对象交互，中介者使各对象不需要显示的相互作用，从而使其耦合松散，而且可以独立的改变它们之间的交互。

备忘录模式（Memento Pattern）
【学习难度：★★☆☆☆，使用频率：★★☆☆☆】
翻译：在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样以后就可将该对象恢复到原来保存的状态。

观察者模式（Observer Pattern）
【学习难度：★★★☆☆，使用频率：★★★★★】
翻译：定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。

状态模式（State Pattern）
【学习难度：★★★☆☆，使用频率：★★★☆☆】
翻译：当一个对象在状态改变时允许其改变行为，这个对象看起来像改变了其类。

策略模式（Strategy Pattern）
【学习难度：★☆☆☆☆，使用频率：★★★★☆】
翻译：定义一组算法，将每个算法都封装起来，并且使他们之间可以互换。

模板方法模式（Template Method Pattern）
【学习难度：★★☆☆☆，使用频率：★★★☆☆】
翻译：定义一个操作中的算法框架，而将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可以重定义该算法的某些特定步骤。

访问者模式（Visitor Pattern）
【学习难度：★★★★☆，使用频率：★☆☆☆☆】
翻译：封装一些作用于某种数据结构中的各种元素，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。