设计模式简介

一：设计模式的概念与意义

1.设计模式的概念

设计模式一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。它描述了在软件设计过程中的一些不断重复发生的问题，以及该问题的解决方案。也就是说，它是解决特定问题的一系列套路，是前辈们的代码设计经验的总结，具有一定的普遍性，可以反复使用。其目的是为了提高代码的可重用性、代码的可读性和代码的可靠性。

2.学习设计模式的意义

设计模式的本质是面向对象设计原则的实际运用，是对类的封装性、继承性和多态性以及类的关联关系和组合关系的充分理解。正确使用设计模式具有以下优点。

• 可以提高程序员的思维能力、编程能力和设计能力。
• 使程序设计更加标准化、代码编制更加工程化，使软件开发效率大大提高，从而缩短软件的开发周期。
• 使设计的代码可重用性高、可读性强、可靠性高、灵活性好、可维护性强。

3.学习原因

开发能力随着经验的增多而提高，每次开发的时候都尽自己的能力做到最好，但是过段时间再看当时自己开发的代码，就会有一种惨不忍睹的感觉。其实说到底还是从一开始没有学习好设计模式，开发的时候考虑不全。所以把乘着这次学习的机会将设计模式简单的整理一下。

二：设计模式分类

总体来说设计模式分为三大类：

创建型模式，共五种：单例模式、工厂方法模式、抽象工厂模式、建造者模式、原型模式。

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

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

其实还有两类：并发型模式和线程池模式。用一个图片来整体描述一下：

这张图好难懂，在学习完设计模式后我们争取对这张图有一个比较清晰的了解哈。

三：设计模式的六大原则

总原则：开闭原则

开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码。

详细介绍:面向对象设计原则之开闭原则

1.里氏代换原则

所有引用基类（父类）的地方必须能透明地使用其子类的对象。
里氏代换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。

里氏替换原则四层含义：

• 子类必须完全实现父类的方法
  在类中调用其他类时务必使用父类或接口，如若不能，则说明类的设计已经违背LSP原则。
  如果子类不能完整的实现父类的方法，或者父类的方法在子类中发生畸变，这建议断开父子继承关系，采用依赖、聚集、组合等方式代替继承。
• 子类可以有自己的特性：即子类出现的地方父类未必可以出现。
• 覆盖父类的方法时输入参数可以被放大：输入参数类型宽于父类的类型的覆盖范围
• 覆盖父类的方法时输出参数可以被缩小

详细介绍：面向对象设计原则之里氏代换原则

2.单一职责原则(SRP)

**定义：**应该有且仅有一个原因引起类的变更。
优点：

类的复杂性降低。类的职责单一，复杂性自然就降低了。
可读性高。
易维护。
变更引起的风险降低。

难点：

“职责”和“变化原因”都是不可度量的，因项目、环境而异。
过细的划分会引起类的剧增，人为的增加系统的复杂性。

建议：

1.接口的设计一定要做到单一原则，类的设计尽量做到只有一个原因引起变化。
2.职责的划分需要根据项目和经验来权衡，既要保证职责的单一性，又要尽量避免过细的划分。

3.依赖倒置原则(DIP)

定义：
1.高层模块不应该依赖低层模块，两者都要改依赖其抽象（模块间的依赖通过抽象产生，实现类不发生直接的依赖关系）
2.抽象不应该依赖细节（接口或者抽象类不依赖实现类）
3.细节可以依赖抽象（实现类依赖接口或者抽象类）

建议：
1.每个类尽量都有接口或抽象类。
2.变量的表面类型尽量是接口或抽象类。
3.任何类都不应该从具体类派生（其实只要不是超过两层的继承都是可以忍受的）。
4.尽量不要复写基类已实现的方法。
5.结合里氏替换原则使用。

面向接口编程：
接口负责定义 public 属性和方法，并且声明与其它对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确实现业务逻辑，同时在适当的时候对父类进行细化。

接口是行为的抽象
抽象类是对一种事物的抽象

4.接口隔离原则

定义：客户端不应该依赖他不需要的接口，类之间的依赖关系应该建立在最小的接口上。

四层含义：
1.接口尽量要小，不要出现臃肿的接口。
2.接口要高内聚。
3.只提供访问者需要的方法：每个接口中不存在子类用不到却必须实现的方法，如果不然，就要将接口拆分。
4.接口设计是有限度的：接口设计粒度越小，系统越灵活。但是结构会越复杂、开发难度增加，可维护性降低。

建议：
1.一个接口只服务一个子模块或者业务逻辑。
2.尽量压缩接口内的方法，保证方法都是有用的，避免臃肿。
3.已经被污染的接口尽量去修改，若变更风险大，则采用适配器模式转化处理。
4.深入了解业务逻辑，拒绝盲从。

5.迪克特原则(最少知道原则)

定义：一个对象应该对其他对象有最少的了解（低耦合）

三层含义：

1.一个类只与朋友交流，不和陌生类交流，方法尽量不引入类中不存在的对象。
2.尽量不要对外暴露过多的 public 方法和非静态的 public 变量，尽量内敛。
3.自己的就是自己的。如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放置在本类中。

总结：
迪米特法则的核心观念就是类间解耦，低耦合。其负面影响就是产生了大量的中转或者跳转类，导致系统复杂性提高，也为维护带来了难度。需要反复权衡，既做到结构清晰，又要高内聚低耦合。
如果一个类需要跳转两次以上才能访问到另一个类，就需要想办法重构了

6. 合成复用原则(CARP)

定义：是在一个新的对象里面使用一些已有的对象，使其成为新对象的一部分。新对象通过委派达到复用已有功能的效果。

优点：
使用对象的合成/聚合将有助于你保持每个类被封装，并被集中在单个任务上。这样类和集成层次会保持较小规模，并且不太可能增长为不可控制的庞然大物。

缺点：
通过这种方式复用建造的系统会有较多的对象需要管理；为了能将多个不同的对象作为组合块来使用，必须仔细地对接口进行定义。

简单地说：尽量首先使用合成/聚合的方式，而不是使用继承。

设计原则参考CSDN文档：https://blog.csdn.net/afei__/article/details/80412746