设计模式

    最近在看设计模式，觉得这篇文章写的不错，就拿来跟大家分享了~

设计模式:

A、 开闭原则（Open-closed principal）：Software entities should be open for extension， but closed for modification

遵循开闭原则设计出的模块具有两个主要特征:

1)对于扩展是开放的（Open for extension）。这意味着模块的行为时可以扩展的。当应用的需求改变时，我们可以对模块进行扩展，使其具有满足那些改变的新行为。也就是说，我们可以改变模块的功能。

2)对于修改是关闭的（Closed for modification）。对模块行为进行扩展时，不必改动模块的源代码或者二进制代码。模块的二进制可执行版本，无论是可链接的库、DLL或者EXE文件，都无需改动。

B、 里氏原则（Liskov Substitution Principal LSP）面向对象设计的基本原则之一。里氏代换原则中说，任务基类可以出现的地方，子类一定也可以出现。LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类傻瓜增加新的行为里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化，而基类与自雷的继承关系就是抽象画的具体实现，所以里氏代换原则是对实现抽象画的具体步骤的规范。

 

注意事项：在进行设计的时候，我们尽量从抽象类继承，而不是从具体类继承。如果从继承等级树来看，所有叶子节点应当是具体类，而所有的树节点应当是抽象类或者接口。当然这个只是一个一般性的指导原则，使用的时候还要具体情况具体分析。

简单的理解为一个软件实体如果使用的是一个父类，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，软件里面，把父类都替换成它的子类，程序的行为没有变化。

 

C、 ISP简介（ISP——Interface Segregation Principal）：

使用多个专门的接口比使用单一的总接口要好。

一个类对另外一个类的依赖性应当是建立在最小的接口上的。

一个接口代表一个角色，不应当将不同的角色都交给一个接口。没有关系的接口合并在一起，形成一个臃肿的大接口，这是对角色和接口的污染。

“不应该强迫客户依赖于他们不用的方法。接口属于客户，不属于它所在的类层次结构”。不要强迫客户使用他们不用的方法，如果强迫客户使用他们不适用的方法，那么这些客户就会面临由于这些不适用的方法的改变所带来的改变。

 

D、 依赖倒置原则 （Dependence Inversion Principal）

A 高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象。

B 抽象不应该依赖于具体，具体应该依赖于抽象

就是要依赖于抽象，不要依赖于具体。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合

 

E、 抽象类

在面向对象的概念中，所有的对象都是通过类来描绘的，但是反过来，并不是所有的类都是用来描绘对象的，如果一个类中没有包含足够的信息来描绘一个具体的对象，这样的类就是抽象类。（例如形状就是一个抽象类）

与具体类比较

1 抽象类不能直接实例化，并且对抽象类使用new运算符会导致编译时错误。虽然一些变量和值在编译时的类型可以使抽象的，但是这样的变量和值必须  或者为null， 或者含有对非抽象类的实例的引用（此非抽象类是从抽象类派生的）。

2 允许（但不要求）抽象类含抽象成员。

3 抽象类不能被密封。

与接口比较

抽象类表示该类中可能已经有一些方法的具体定义，但是接口就仅仅只能定义各个方法的界面（方法名，参数列表，返回类型），并不关心具体细节。

接口是引用类型的，和抽象类的相似之处有三点：

1 不能实例化

2 包含未实现的方法声明

3 派生类必须实现未实现的方法，抽象类是抽象方法，接口则是所有成员（不仅是方法包括其他成员）。

抽象类于接口紧密相关。然而接口又比抽象类更抽象，这主要体现在它们的差别上：

1 类可以实现无限个接口，但仅能从一个抽象类继承，从抽象类派生的类任可是实现接口，从而得出接口是用来解决多重继承问题的。

2 抽象类当中可以存在非抽象的方法，可接口不能，且它里面的方法只能是一个声明必须用public来修饰没有具体实现的方法。

3 抽象类中的成员变量可以被不同的修饰符来修饰，可接口中的成员变量默认的都是静态常亮（static final）。

4 抽象类是对象的抽象，然而接口是一种行为规范。