设计模式的六大原则实例

一、设计模式的六大原则1、开闭原则（Open Close Principle）开闭原则就是说对扩展开放，对修改关闭。

在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。

所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。

想要达到这样的效果，我们需要使用接口和抽象类。

开闭原则是面向对象的可复用设计的第一块基石。

开闭原则的关键是抽象化。

2、里氏代换原则（Liskov Substitution Principle）里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。

里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。

LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。

里氏代换原则是对“开-闭”原则的补充。

实现“开-闭”原则的关键步骤就是抽象化。

而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

面向对象的设计关注的是对象的行为，它是使用“行为”来对对象进行分类的，只有行为一致的对象才能抽象出一个类来。

我经常说类的继承关系就是一种“Is-A”关系，实际上指的是行为上的“Is-A”关系，可以把它描述为“Act-As”。

3、依赖倒转原则（Dependence Inversion Principle）这个是开闭原则的基础，具体内容：真对接口编程，依赖于抽象而不依赖于具体。

4、接口隔离原则（Interface Segregation Principle）这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。

还是一个降低类之间的耦合度的意思，从这儿我们看出，其实设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。

所以上文中多次出现：降低依赖，降低耦合。

5、迪米特法则（最少知道原则）（Demeter Principle）最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。

6、合成复用原则（Composite Reuse Principle）合成/聚合复用原则是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到复用已有功能的目的。

合成(Composition)和聚合(Aggregation)都是关联(Association)的特殊种类。

原则是尽量使用合成/聚合的方式，而不是使用继承。

11.开闭原则实例Fruit接口：抽象产品Orange类：实现fruit接口，具体产品Apple类：实现Fruit接口，具体产品Gardener接口：抽象工厂AppleGardener类：实现Gardener接口，具体工厂，分管apple生产OrangeGardener类：实现Gardener接口，具体工厂，分管orange生产package interface Fruit {OrangeOrange.");}}public class Driver {.");}}public class BMW implements ICar{.");}}在业务场景中，我们贯彻“抽象不应该依赖细节”，也就是我们认为抽象（ICar接口）不依赖BMW和Benz两个实现类（细节），因此我们在高层次的模块中应用都是抽象，Client的实现过程如下：public class Client {public static void main(String[] args) {IDriver zhangSan = new Driver();ICar benz = new Benz();口隔离原则public interface IPettyGirl {name=name;}(this. name + "---脸蛋很漂亮!");}(this. name + "---气质非常好!");}(this. name + "---身材非常棒!");}}public abstract class AbstractSearcher {protected IPettyGirl pettyGirl;public AbstractSearcher(IPettyGirl _pettyGirl){= _pettyGirl;}("--------美女的信息如下： ---------------");();();();}}public class Client {name=_name;}(this. name + "---脸蛋很漂亮!");}(this. name + "---气质非常好!");}(this. name + "---身材非常棒!");}}通过这样的改造以后，不管以后是要气质美女还是要外形美女，都可以保持接口的稳定。

当然你可能要说了，以后可能审美观点再发生改变，只有脸蛋好看就是美女，那这个 IGoodBody 接口还是要修改的呀，确实是，但是设计时有限度的，不能无限的考虑未来的变更情况，否则就会陷入设计的泥潭中而不能自拔。

以上把一个臃肿的接口变更为两个独立的接口依赖的原则就是接口隔离原则，让 AbstractSearcher 依赖两个专用的接口比依赖一个综合的接口要灵活。

接口是我们设计时对外提供的契约，通过分散定义多个接口，可以预防未来变更的扩散，提高系统的灵活性和可维护性。

55.迪米特法则如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。

如果其中的一个类需要调用另外一个类的某一个方法，可以通过第三者转发这个调用。

参考下例，Someone、Friend和Stranger三个类。

public class Someone{public void operation1( Friend friend ){Stranger stranger = () ;() ;}}所以Someone和Friend是朋友类（直接通讯的类）。

同理，Friend类持有一个Stranger类的私有对象，他们是朋友类：public class Friend{private Stranger stranger = new Stranger() ;public void operation2(){}public Stranger provide(){return stranger ;}}在这里，Someone类和Stranger类不是朋友类，但Someone类却通过Friend 类知道了Stranger类的存在，这显然违反迪米特法则。

现在，我们对Someone和Friend类进行重构。

首先在Friend类里添加一个方法，封装对Stranger类的操作：public class Friend{private Stranger stranger = new Stranger() ;public void operation2(){}public Stranger provide(){return stranger ;}public void forward(){() ;}}然后，我们重构Someone的operation1方法，让其调用新提供的forward 方法：public class Someone{() ; }}现在Someone对Stranger的依赖完全通过Friend隔离，这样的结构已经符合狭义迪米特法则了。

仔细观察上述结构，会发现狭义迪米特法则一个明显的缺点：会在系统里造出大量的小方法，散落在系统的各个角落。

这些方法仅仅是传递间接的调用，因此与系统的商务逻辑无关，当设计师试图从一张类图看出总体的框架时，这些小的方法会造成迷惑和困扰。

遵循迪米特法则会使一个系统的局部设计简化，因为每一个局部都不会和远距离的对象有直接关联。

但是，这也会造成系统的不同模块之间的通信效率降低，也会使系统的不同模块之间不容易协调。

结合依赖倒转原则，我们对代码进行如下重构来解决这个问题，首先添加一个抽象的Stranger类，使Someone依赖于抽象的“Stranger”角色，而不是具体实现：public abstract class AbstractStranger{abstract void operation3() ;}然后，让Stranger从该类继承：public class Stranger extends AbstractStranger{public void operation3() {}}随后，我们重构Someone使其依赖抽象的Stranger角色：public class Someone{AbstractStranger stranger = () ;() ; }}最后，我们重构Friend的provide方法，使其返回抽象角色：public class Friend{private Stranger stranger = new Stranger() ;public void operation2(){}public AbstractStranger provide(){return stranger ;}}现在，AbstractStranger成为Someone的朋友类，而Friend类可以随时替换掉AbstractStranger的实现类，Someone不再需要了解Stranger的内部实现细节。

下图是重构后的UML类图：在将迪米特法则运用到系统的设计中时，应注意的几点：①在类的划分上，应该创建有弱耦合的类；②在类的结构设计上，每一个类都应当尽量降低成员的访问权限；③在类的设计上，只要有可能，一个类应当设计成不变类；④在对其他类的引用上，一个对象对其它对象的引用应当降到最低；⑤尽量降低类的访问权限；⑥谨慎使用序列化功能；⑦不要暴露类成员，而应该提供相应的访问器(属性)。

66、合成复用原则实例（1）聚合用来表示“拥有”关系或者整体与部分的关系。

代表部分的对象有可能会被多个代表整体的对象所共享，而且不一定会随着某个代表整体的对象被销毁或破坏而被销毁或破坏，部分的生命周期可以超越整体。

例如，班级和学生，当班级删除后，学生还能存在，学生可以被培训机构引用。

class Student {private String sName;}class Classes{private Student student;public Classes(Student student){=student;}}（2）合成用来表示一种强得多的“拥有”关系。