设计模式（Design Patterns）

1.面向对象基本概念【OO(Object-Oriented) Basics】

抽象（Abstraction）

封装（Encapsulation）

继承（Inheritance）

多态（Polymorphism）

 

2. Design Principle 1

 

找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起（封装变化点）

 

把会变化的部分取出并“封装”起来，以便以后可以轻易地修改或扩充此部分，而不影响不需要变化的其他部分

 

Identify the aspects for your application that vary and separate them from what stays the same.

Here's another way to think about this principle:

take the parts that vary and encapsulate them,so that later you can alter or extend the parts that vary without affecting those that don't

 

 

3. Design Pinciple 2

 

针对接口编程，而不是针对实现编程

 

”针对接口编程“真正的意思是“针对超类型（supertype）编程”

 

这里所谓的“接口”有多个含义，接口是一个“概念”，也是一种Java的interface构造。你可以在不涉及Java interface的情况下，“针对接口编程”，关键就在多态。利用多态，程序可以针对超类型编程，执行时会根据实际状况执行到真正的行为，不会被绑死在超类型的行为上。“针对超类型编程”这句话，可以更明确地说成“变量的声明类型应该是超类型，通常是一个抽象类或者是一个接口，如此，只要是具体实现此超类型的类所产生的对象，都可以指定给这个变量。这也意味着，声明类时不用理会以后执行时的真正对象类型！”

 

Program to an interface,not an implementation

 

"Program to an interface" really means "Program to a supertype"

 

The point is to exploit polymorphism by programming to a supertype so that the actual runtime object isn't locked into the code,And we could rephrase "program to a supertype" as "the declared type of the variables should be a supertype,usually an abstract class or interface",so that the objects assigned to those variables can be of any concrete implementation of the supertype,which means the class declaring them doesn't have to know about the actual object types!"

 

4. Design Principle 3

 

优先使用对象组合吗，而不是类继承

 

使用组合简历系统具有很大的弹性，不仅可将算法族封装成类，更可以“在运行时动态地改变行为”，只要组合的行为对象符合正确的接口标准即可。

 

Favor composition over inheritance 

 

Creating system using composition gives you a lot more flexibility.Not only does it let you encapsulate a family of algorithms into their own set of classes,but it also lets you change behavior at runtime as long as the object you are composing with implements the correct behavior interface.

 

OO设计原则：

 

【单一职责原则】：就一个类而言，应该仅有一个引起它变化的原因

 

【开放封闭原则】：类应该对扩展开发，对修改关闭（关键是抽象，将一个功能的通用部分和实现细节部分清晰的分离开来， 应该仅仅对程序中呈现出频繁变化的那些部分作出抽象）

 

【李氏替换原则】：子类型(subclass)必须能够替换掉它们的基类型(superclass)

 

【依赖倒置原则】：要依赖抽象，不要依赖具体类（抽象不应该依赖于细节，细节应该依赖于抽象，程序中所有的依赖关系都应该终止于抽象类和接口，针对接口而非实现编程）

 

【接口隔离原则】：不应该强迫客户依赖于它们不用的方法

 

【接口设计原则】：IDP(Interface Design Principle)，规划一个接口而不是实现一个接口

 

【缺省抽象原则】：DAP(Default Abstraction Principle)，在接口和实现接口的类之间引入一个抽象类，这个类实现了接口的大部分操作

 

【黑盒原则】：BBP(Black Box Principle)，多用类的聚合，少用类的继承

 

包的内聚性原则： 

1) 重用发布等价原则(The Release Reuse Equivalency Principle (REP)) 
* 重用的粒度就是发布的粒度 
* 一个可重用的包必须为发布跟踪系统所管理，使我们在新版本发布后我们还可以继续使用老版本 
* 一个包中的所有类对于同一类用户来讲都应该是可重用的。 

2) 共同重用原则(The Common Reuse Principle (CRP)) 
*　一个包中的所有类应该是共同重用的，如果重用了包中的一个类，就应该重用包中的所有类。 
*　一般来说，可重用的类需要与作为该可重用抽象一部份的其它类协作，CRP规定了这些类应该属于同一个包。 
* 放入同一包中的所有类应该是不可分开的，其它包仅仅依赖于其中一部份情况是不可能的（不允许的），否则，我们将要进行不必要的重新验证与重新发布，并且会白费相当数量的努力。（一个包依赖于另外一个包，　哪怕只是依赖于其中的一个类也不会削弱其依赖关系） 
* CRP倾向于把包做的尽可能的小 

3) 共同封闭原则(The Common Closure Principle (CCP)) 
*　包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中所有类产生影响，而对于其他的包不造成任何影响。 
* 这是单一职责原则对于包的重新规定。 
* CCP鼓励我们把可能由于同样的原因而更改的所有类共同聚集在同一个地方。将变化限制在最小数据的包中。 
* CCP倾向于将包做的尽可能的大。 
* CCP有益于维护者(包的作者)，而REP和CRP有益于重用者(包的使用者)。 

包的耦合性原则：

1) 无环依赖原则(The Acyclic Dependencies Principle (ADP)) 
* 在包的依赖关系图中不允许存在环。 
* 包的依赖关系图应该是一个有向无环图(DAG(Directed Acyclic Grphic)) 
* 存在环的系统，很难确定包的构建顺序，事实上，并不存在恰当的构建顺序。 
* 打破环的第一个方法：依赖倒置原则，使一个包不再依赖于另一个包，而只是依赖于其抽象接口。 
* 打破环的第二个方法: 创建一个新包来包含公共依赖部份。 

2) 稳定依赖原则(The Stable Dependencies Principle (SDP)) 
* 朝着的稳定的方向进行依赖 
* 你设计了一个易于更改的包，　其它人只要创建一个对它的依赖就可以使它变的难以更改，这就是软件的反常特性。通过遵循SDP可以避免这种情况。 
* 不稳定性度量：I = Ce / (Ca + Ce).　Ca: Afferent Coupling. Ce: Efferent Coupling 
* SDP规定一个包的I度量值应该大于它所依赖的包的I的度量值，也就是说，I的度量值应该顺着依赖的方向减少。 

3) 稳定抽象原则(The Stable Abstractions Principle (SAP)) 
* 包的抽象程度应该和其稳定程度一致。 
* 一个稳定的包同时应该是抽象的，这样，其稳定性就不会导致其无法扩展。一个不稳定的包应该是具体的，这样，因为其不稳定性使得其内部的具体代码易于修改。 
* 抽象性度量：A = Na / Nc Na: Number of classes. Nc:Number of abstract classes. 
* 创建一个以A为纵轴，I为横轴的坐标图，最稳定，最抽象的包位于左上角(0,1)处，　那些最不稳定，最具体的包位于右下角(1,0)处。 

 

23种设计模式 - Pattern：

 

创建型：

Abstract Factory（抽象工厂模式） -> (简单工厂模式) 

Factory Method（工厂模式） 

Builder（生成器模式） 

Singleton（单件模式） -> (多例模式) 

Prototype（原型模式）

 

结构型： 

Adapter（适配器模式） 

Bridge（桥接模式） 

Composite（组合模式） 

Decorator（装饰模式） 

Facade（外观模式，门面模式） 

Flyweight（享元模式） -> (不变模式) 

Proxy（代理模式）

 

行为型：

Chain of Responsibility（职责链模式） 

Command（命令模式） 

Interpreter（解释器模式） 

Iteartor（迭代器模式） 

Mediator（中介者模式） 

Memento（备忘录模式） 

Observer（观察者模式） 

State（状态模式） 

Strategy（策略模式） 

TemplateMethod（模板方法模式） 

Visitor（访问者模式） 

 

 

 1.【观察者模式】：定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新；主题（Subject）和观察者（Observer）定义了一对多的关系。

 

 

【松耦合】

 

当两个对象之间松耦合，他们依然可以交互，但是不太清楚彼此的细节。

 

观察者模式提供了一种对象设计，让主题和观察者之间松耦合。

 

主题只知道观察者实现了某个接口（Observer接口），主题不需要知道观察者的具体类是谁、做了些什么或其他任何细节。

 

任何时候我们都可以增加新的观察者。因为主题唯一依赖的东西是一个实现了Observer接口的对象列表，所以我们可以随时增加观察者，也可以在任何时候删除某些观察者。

 

有新类型的观察者出现时，主题的代码不需要修改。新类型的观察者只要实现观察者接口（Observer接口），然后注册为观察者即可。主题不在乎别的，他只会发送通知给所有实现了观察者接口的注册对象。

 

改变主题或观察者其中一方，并不会影响另一方。因为两者是松耦合的，所以只要他们之间的接口仍被遵守，我们就可以自由地改变他们。

 

 观察者模式采用主题【推】的模式，将主题的变动通知所有注册的观察者，而不是采用观察者【拉】的模式。

 

 

2.【装饰模式】：装饰者和被装饰对象有相同的超类型，动态地将责任附加到对象上，若要扩展功能，装饰者提供了比继承更有弹性的替代方案。

 

 

 

 

3.【工厂方法模式】：定义了一个创建对象的接口，但由子类决定要实例化的类时哪一个。工厂方法让类把实例化推迟到子类。

 

 

利用工厂方法创建对象，需要扩展一个类（使用继承），并覆盖他的工厂方法，通过子类来创建对象，由子类来负责决定具体类型。把客户代码从需要实例化的具体类中解耦。

 

 

 4.【抽象工厂模式】：提供一个接口，用于常见相关或依赖对象的家族，而不需要明确指定具体类。

 

抽象工厂允许客户使用抽象的接口来创建一组相关的产品，而不需要知道（或关心）实际产出的具体产品是什么。这样一来，客户就从具体的产品中被解耦。

 

 

 

抽象工厂的方法经常以工厂方法的方式实现。抽象工厂的任务是定义一个负责创建一组产品的接口。这个接口内的每个方法都负责创建一个具体产品。我们利用实现抽象工厂的子类来提供这些具体的做法。所以，在抽象工厂中利用工厂方法实现生产方法是相当自然的做法。

 

 抽象工厂提供一个用来创建一个产品家族的抽象类型，这个类型的子类定义了产品被产生的方法。把客户从所使用的实际具体产品中解耦。