设计模式的分类 凭据其目的（模式是用来做什么的）可分为建立型(Creational)，构造型(Structural)和行为型(Behavioral)三种：
建立型模式首要用于建立对象。
构造型模式首要用于处理类或对象的组合。
行为型模式首要用于描述对类或对象如何交互和如何分派职责。
建立型模式
抽象工场模式(Abstract Factory)
建造者模式(Builder)
工场方式模式(Factory Method)
原型模式(Prototype)
单例模式(Singleton)
构造型模式
适配器模式(Adapter)
桥接模式(Bridge)
组合模式(Composite)
装饰模式(Decorator)
外观模式(Facade)
享元模式(Flyweight)
代理模式(Proxy)
行为型模式
职责链模式(Chain of Responsibility)
号令模式(Command)
注释器模式(Interpreter)
迭代器模式(Iterator)
中介者模式(Mediator)
备忘录模式(Memento)
视察者模式(Observer)
状况模式(State)
策略模式(Strategy)
模板方式模式(Template Method)
接见者模式(Visitor)
凭据局限（模式首要是用于处理类之间关系照样处理对象之间的关系）可分为类模式和对象模式两种：
类模式处理类和子类之间的关系，这些关系经由继续竖立，在编译时刻就被确定下来，是属于静态的。
对象模式处理对象间的关系，这些关系在运行时刻转变，更具动态性。
类模式
工场方式模式(Factory Method)
适配器模式(Adapter)
注释器模式(Interpreter)
模板方式模式(Template Method)
对象模式
抽象工场模式(Abstract Factory)
建造者模式(Builder)
原型模式(Prototype)
单例模式(Singleton)
桥接模式(Bridge)
组合模式(Composite)
装饰模式(Decorator)
外观模式(Facade)
享元模式(Flyweight)
代理模式(Proxy)
职责链模式(Chain of Responsibility)
号令模式(Command)
迭代器模式(Iterator)
中介者模式(Mediator)
备忘录模式(Memento)
视察者模式(Observer)
状况模式(State)
策略模式(Strategy)
接见者模式(Visitor)
六大原则
总原则：开闭原则
界说：一个软件实体如类、模块或函数应该对扩睁开放，对点窜封闭。
简洁的说就是，当一个软件实体需要扩展的时候，不要去点窜原有的代码，而是去扩展原有的代码。其实开闭原则是最根蒂的一个原则，下面六个原则都是开闭原则的具体形态。
为什么要采用开闭原则：
1、对测试的影响：经由扩展实现转变，测试只需要对新增类进行单元测试即可，单元测试是孤立的，只需要包管新类供应的方式准确就行。而若是是点窜类来实现转变，则该类响应的测试方式也都要跟着重构，并且当类很复杂时不免存在漏掉情形。
2、能够提高复用性：避免今后维护人员为了点窜一个微小的缺陷或增加新功能，却要在整个项目中四处查找相关的代码一一点窜。
3、提高可维护性：斥地新功能时，扩展一个类往往比点窜一个类更轻易。
4、面向对象斥地的要求
单一职责原则
界说：应该有且仅有一个原因引起类的调换。
长处：
1、类的复杂性降低。类的职责单一，复杂性天然就降低了。
2、可读性高。
3、易维护。
4、调换引起的风险降低。
难点：
1、\"职责\"和\"转变原因\"都是弗成器量的，因项目、情况而异。
2、细致的划分会引起类的剧增，工资的增加系统的复杂性。
建议：
接口的设计必然要做到单一原则，类的设计尽量做到只有一个原因引起转变。
职责的划分需要凭据项目和经验来衡量，既要包管职责的单一性，又要尽量避免细致的划分。
里氏替代原则
界说：所有引用基类的处所都必需能透亮地使用其子类的对象。
继续的长处：
1、代码共享，提高代码的重用性。
2、提高代码的可扩展性。
3、提高产物或许项目的开放性。
继续的瑕玷：
1、继续是侵入式的，只要继续，就拥有了父类的属性和方式。
2、降低代码天真性，子类拥有了父类的属性和方式，多了一些约束。
3、增加了耦合性。父类的常量、变量或方式篡改时，必需还要考虑子类的点窜，或者会有大段代码需要重构。
里氏替代原则四层寄义：
1、子类必需完全实现父类的方式
在类中挪用其他类时务必使用父类或接口，如若不克，则解说类的设计已经违反LSP原则。
若是子类不克完整的实现父类的方式，或许父类的方式在子类中发生畸变，这建议断开父子继续关系，采用依靠、群集、组合等体式取代继续。
2、子类能够有本身的特征：即子类显现的处所父类未必能够显现。
3、笼盖父类的方式时输入参数能够被放大：输入参数类型宽于父类的类型的笼盖局限，例如 hashmap -> map。
4、笼盖父类的方式时输出参数能够被缩小
依靠倒置原则
界说：
1、高层模块不该该依靠低层模块，两者都要改依靠其抽象（模块间的依靠经由抽象发生，实现类不发生直接的依靠关系）
2、抽象不该该依靠细节（接口或许抽象类不依靠实现类）
3、细节能够依靠抽象（实现类依靠接口或许抽象类）
建议：
1、每个类尽量都有接口或抽象类。
2、变量的外观类型尽量是接口或抽象类。
3、任何类都不该该从具体类派生（其实只要不是跨越两层的继续都是能够忍耐的）。
4、尽量不要复写基类已实现的方式。
5、连系里氏替代原则使用。
面向接口编程：
接口负责界说 public 属性和方式，而且声明与另外对象的依靠关系，抽象类负责民众组织部门的实现，实现类正确实现买卖逻辑，同时在适当的时候对父类进行细化。
接口隔离原则
界说：客户端不该该依靠他不需要的接口，类之间的依靠关系应该竖立在最小的接口上。
四层寄义：
1、接口尽量要小，不要显现痴肥的接口。
2、接口要高内聚。
3、只供应接见者需要的方式：每个接口中不存在子类用不到却必需实现的方式，若是否则，就要将接口拆分。
4、接口设计是有限度的：接口设计粒度越小，系统越天真。然则构造会越复杂、斥地难度增加，可维护性降低。
建议：
1、一个接口只办事一个子模块或许买卖逻辑。
2、尽量压缩接口内的方式，包管方式都是有效的，避免痴肥。
3、已经被污染的接口尽量去点窜，若调换风险大，则采用适配器模式转化处理。
4、深入认识买卖逻辑，拒绝盲从。
迪克特轨则（起码知道原则）
界说：一个对象应该对其他对象有起码的认识（低耦合）。
三层寄义：
1、一个类只与同伙交流，不和生疏类交流，方式尽量不引入类中不存在的对象。
2、尽量不要对外露出过多的 public 方式和非静态的 public 变量，尽量内敛。
3、本身的就是本身的。若是一个方式放在本类中，既不增加类间关系，也对本类不发生负面影响，那就放置在本类中。
总结：
迪米特轨则的焦点观点就是类间解耦，低耦合。其负面影响就是发生了大量的中转或许跳转类，导致系统复杂性提高，也为维护带来了难度。需要频频衡量，既做到构造清楚，又要高内聚低耦合。
若是一个类需要跳转两次以上才能接见到另一个类，就需要想法子重构了。
合成复用原则
界说：
是在一个新的对象里面使用一些已有的对象，使其成为新对象的一部门。新对象经由委派达到复用已有功能的结果。
长处：
使用对象的合成/聚合将有助于你连结每个类被封装，并被集中在单个义务上。如许类和集成条理会连结较小规模，而且不太或者增进为弗成掌握的庞然大物。
瑕玷：
经由这种体式复用建造的系统会有较多的对象需要治理；为了能将多个分歧的对象作为组合块来使用，必需细心地对接口进行界说。
简洁地说：尽量首先使用合成/聚合的体式，而不是使用继续。
