设计模式总览

一、设计模式来历–四人帮

在 1994 年，由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 四人合著出版了一本名为 《Design Patterns - Elements of Reusable Object-Oriented Software》 的书，该书首次提到了软件开发中设计模式的概念。四位作者合称 GOF（四人帮，全拼 Gang of Four）。

设计模式是为了让程序具有更好的：代码复用性、可读性、可扩展性、可靠性和使程序呈现高内聚、低耦合的特性。

二、设计模式分类

三、设计模式的七大原则

核心思想：

• 找出应用中可能需要变化之处，把它们从那些不需要变化的代码独立出来
• 针对接口编程，而不是针对实现编程
• 为了交互对象之间的松耦合设计而努力

单一职责原则

• 对类来说，即一个类应该只负责一项职责。如果类A同时负责职责A和职责B，当为了职责1需求变更而改变A时，可能造成职责2执行错误，所以需要将类A的粒度分解为A1、A2。

接口隔离原则（Interface Segregation Principle）

• 客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上。使用多个隔离的接口，比使用单个接口要好，降低类之间的耦合度。
• 一个接口i有m1、m2、m3、m4等四个方法，类B和类C分别实现了接口i，类A依赖类B，只使用了m1和m2两个方法，类C依赖类B，只使用了m3和m4两个方法。此时按照接口隔离原则需要将接口i拆分成接口i1和接口i2，其中i1包含m1和m2两个方法，i2包含m3和m4两个方法。

依赖倒转原则（Dependence Inversion Principle）

• 高层模块不应该依赖底层模块，二者都应该依赖其抽象
• 抽象不应该依赖细节，细节应该依赖抽象
• 依赖倒转（倒置）的中心思想是面向接口编程
• 设计理念：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在Java中，抽象指的是接口或抽象类，细节就是指具体的实现
• 使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成
• 依赖关系传递的三种方式：接口传递、构造方法传递和setter方式传递

里氏代换原则（Liskov Substitution Principle）

• 里氏代换原则是面向对象设计的基本原则之一
• 引用基类的地方必须能透明地使用其子类对象
• 在继承关系中，遵循LSP原则，在子类中尽量不要重写父类的方法，可以在基类的基础上增加新的行为
• 里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范

开闭原则（Open Close Principle）

• 对扩展开放（对提供方），对修改关闭（使用方）
• 在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果，使程序的扩展性好，易于维护和升级，如抽象类与接口的设计

迪米特法则，又称最少知道原则（Demeter Principle）

• 一个对象应该对其他对象保持最少的了解，类与类关系越密切，耦合度越大
• 最少知道原则：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。即一个类对自己依赖的类知道的越少越好，也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的public方法，不泄露任何信息

合成复用原则（Composite Reuse Principle）

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

• 类与类之间的关系：依赖、泛化（继承）、实现、关联、聚合与组合。

  • 依赖：只要在类中使用到了对方，就存在依赖关系，如成员属性、方法参数类型、方法返回类型、方法内部使用等等。
  • 泛化：依赖关系的特例，实际上就是继承关系，是依赖关系的特例。
  • 实现：接口与实现类的关系，是依赖关系的特例。
  • 关联：关联具有导航性，即单向关系与双向关系，可表示为一对一、一对多或多对多关系，是依赖关系的特例。
  • 聚合：表示整体和部分的关系，整体与部分可以分开，是关联关系的特例。如电脑是一个整体，包含键盘和鼠标等外设，可分离。
  • 组合：表示整体和部分的关系，但整体与部分不可以分开，是关联关系的特例。如人有手有脚，不能分开。

最后

以上就是帅气帆布鞋为你收集整理的设计模式总览的全部内容，希望文章能够帮你解决设计模式总览所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。