本文摘要：设计模式的分类 凭据其目的（模式是用来做什么的）可分为建立型(Creational)，结构型(Structural)和行为型(Behavioral)三种： 建立型模式主要用于建立工具。结构型模式主要用于处置惩罚类或工具的组合。行为型模式主要用于形貌对类或工具怎样交互和怎样分配职责。

设计模式的分类 凭据其目的（模式是用来做什么的）可分为建立型(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、自己的就是自己的。如果一个方法放在本类中，既不增加类间关系，也对本类不发生负面影响，那就放置在本类中。总结：迪米特规则的焦点看法就是类间解耦，低耦合。

其负面影响就是发生了大量的中转或者跳转类，导致系统庞大性提高，也为维护带来了难度。需要重复权衡，既做到结构清晰，又要高内聚低耦合。

如果一个类需要跳转两次以上才气会见到另一个类，就需要想措施重构了。合成复用原则界说：是在一个新的工具内里使用一些已有的工具，使其成为新工具的一部门。新工具通过委派到达复用已有功效的效果。

优点：使用工具的合成/聚合将有助于你保持每个类被封装，并被集中在单个任务上。这样类和集成条理会保持较小规模，而且不太可能增长为不行控制的庞然大物。缺点：通过这种方式复用制作的系统会有较多的工具需要治理；为了能将多个差别的工具作为组合块来使用，必须仔细地对接口举行界说。

简朴地说：只管首先使用合成/聚合的方式，而不是使用继续。

本文关键词：设计模式,分类,以及,六大,设计,天博app下载,原则

本文来源：天博app-www.byldkj.com