设计模式原则和分类

为什么会有设计模式?

设计模式（Design Pattern）是一套被反复使用、多数人知晓的、经过分类的、代码设计经验的总结。

设计模式（Design pattern）代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。

 

简单总结一下就是一种更好的，更优雅的解决问题的方式。但是也有一个需要注意的地方，就是不要为了设计而设计，毕竟我们的出发点是为了解决问题而不是为了设计。

 

因为本人也是入行不久的小白,而设计原则这个东西也是一个雅俗共赏,千人千面的东西。博客中写的也是我在参考了其他人的博客和书籍之后给出的理解，所以理解难免会有偏差，欢迎评论留言指正，一起学习讨论。

 

设计模式的原则

1.开闭原则(Open Close Principle)

对扩展开放，对修改关闭。具体到实际开发就是对程序进行扩展的时候，不能去修改原有的代码，而是要在原有代码的基础上进行扩展。这里可以用到抽象类和接口。基于顶层方法进行不同的实现，或则在实现里增加新的方法

2.里氏代换原则（Liskov Substiution Princicle）

里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。就是父类出现的地方把代码换成子类也可以正常运行不受影响。扩展的时候也尽量从抽象类继承，而不要去继承实现类。这个原则可以参考三人成虎这个典故。在扩展的时候尽量不要偏离这个类原有的定义。

3.单一职责原则（Single Responsibility Principle）

这个模式可以用来控制类的粒度，就是一个类不要不要做太多事情，只做一件事。这个原则是实现代码高内聚，低耦合的指导方针。不过具体到实际开发还是很难实现的，比如用户注册的功能，以前三个方法可能就搞定了，按照这个原则你可能需要把每一个步骤都拆分成独立的方法，但是这些方法可能一个项目里就两三个地方用到，这种情况下是否还有单独拆出来的必要呢？

4.依赖倒转原则（Dependence Inversion Principle）

抽象不应该依赖于实现，细节应该依赖于实现。应用到代码里就是一个接口的抽象度要足够高，不然业务一旦扩展之后再去新创建的类再继承这个类就会发现要实现的功能和基类定义的方法表达的意思差的远了，需要重新新增加方法，而不是重写方法。用到这里类的地方有spring的自动注入。

5.迪米特法则（最少知道原则）（Demeter Principle）

一个实体应该尽可能少的与其他实体之间发生关系。使得系统模块相对独立。这一点也是微服务的一个重要原则。

6.接口隔离原则（Interface Segregation Principle）

使用多个专门的接口，而不是使用一个接口来完成所有的事情。也就要高度抽象，这个和迪米特法则也是联系在一起的。说的再通俗一点就是做自己该做的事情。

7.合成复用原则（Composite Reuse Principle）

在一个新对象里使用已有的对象，使之成为新对象的一部分，新对象将需要做的大功能分成各个小功能传达到其他模块来完成，最后完成这大功能。具体到代码就是尽量使用组合，不要使用继承。

 

设计模式分类

创建型模式（5种）：工厂方法模式，抽象工厂模式，单例模式，建造者模式，原型模式。

结构型模式（7种）：适配器模式，装饰器模式，代理模式，外观模式，桥接模式，组合模式，享元模式。

行为型模式（11种）：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

 

还有另外两个，并发型模式和线程池模式。