文章目录

• 一、 设计模式（Design Pattern,DP）
• • 1.1、**产生背景**
  • 1.2、设计模式的概念
• 二、设计模式六大设计原则
• • 2.1、开闭原则：Open Closed Principle，OCP
  • • 2.1.1、 开闭原则的定义
    • 2.1.2、开闭原则的作用
  • 2.2、单一职责原则：Single responsibility principle，SRP
  • • 2.2.1、背景
    • 2.2.2、定义概念
    • 2.2.3、 单一职责原则的优点
  • 2.3、里氏替换原则 Liskov Substitution Principle，LSP
  • • 2.3.1、里氏替换原则定义
    • 2.2.3、里氏替换原则的作用
• 总结

一、 设计模式（Design Pattern,DP）

1.1、产生背景

1. “设计模式”这个术语最初并不是出现在软件设计中，而是被用于建筑领域的设计中。 2. 直到 1990 年，软件工程界才开始研讨设计模式的话题。 3. 1995年，“四人组”（Gang of Four，GoF）合作出版了《设计模式：可复用面向对象软件的基础》（Design Patterns: Elements of Reusable Object-Oriented Software）一书，在书籍中收录了 23 个设计模式，这是设 计模式领域里程碑的事件，导致了软件设计模式的突破。 4. 直到今天，狭义的设计模式还是该书中所介绍的23种经典设计模式。

1.2、设计模式的概念

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

二、设计模式六大设计原则

2.1、开闭原则：Open Closed Principle，OCP

2.1.1、 开闭原则的定义

开闭原则由勃兰特·梅耶（Bertrand Meyer）提出，他在 1988 年的著作《面向对象软件构造》（Object Oriented Software Construction）中提出：软件实体应当对扩展开放，对修改关闭（Software entities should be open for extension，but closed for modification），这就是开闭原则的经典定义。
简单点说就是是：一个软件实体应 该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。那么什么是软件实体呢br> 这里的软件实体包括以下几个部分：
1. 项目中划分出的模块
2. 类与接口
3. 方法
一个软件产品在她的生命周期内一般都会发生变化，开闭原则视为软件实体的未来事件而制定的对现行开发设计进 行约束的一个原则。

举个例子：以书店图书销售为例：

运行结果:

2.1.2、开闭原则的作用

开闭原则是面向对象程序设计的终极目标，它使软件实体拥有一定的适应性和灵活性的同时具备稳定性和延续性。
具体来说，其作用如下：

1. 对软件测试的影响
   软件遵守开闭原则的话，软件测试时只需要对扩展的代码进行测试就可以了，因为原有的测试代码仍然能够正常运 行。
2. 可以提高代码的可复用性
   粒度越小，被复用的可能性就越大；在面向对象的程序设计中，根据原子和抽象编程可以提高代码的可复用性。
3. 可以提高软件的可维护性
   遵守开闭原则的软件，其稳定性高和延续性强，从而易于扩展和维护。

2.2、单一职责原则：Single responsibility principle，SRP

2.2.1、背景

这是一个备受争议的原则，跟人吵架的时候这个是屡试不爽的一个梗。
为什么会备受争议呢么就能吵起来呢要就是对职责如何定义，什么是类的职责，以及怎么划分类的职责。
举个栗子：老师对学生有很多的工作要做：例如了解个人信息、每天的学习情况、记录考勤；回答学生问题，帮助解决bug,重难点串讲；行业经验分享等。

如果将这些工作交给一位老师负责显然不合理，正确的做法是：班主任负责日常工作，技术辅导老师负责技术辅导；企业师傅负责行业经验分享等。

2.2.2、定义概念

单一职责原则（Single Responsibility Principle，SRP）又称单一功能原则，由罗伯特·C.马丁（Robert C. Martin）于《敏捷软件开发：原则、模式和实践》一书中提出的。这里的职责是指类变化的原因，单一职责原则规 定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分（There should never be more than one reason for a class to change）。

该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点：
1. 一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力；
2. 当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码 的浪费。

以上是符合单一职责原则的吗白了是一个接口只负责一件事情吗只有一个原因引起变化么好像不是哦！
其实他负责了两个内容：
1、协议管理，2、数据传送。
dial()和hangup()两个方法实现的是协议管理；chat()方法负责的是数据的传送。那么协议的改变可能引起接口或者 实现类的变化；同样数据传送（电话不仅可以打电话，还能上 ）的变化也可能会引起接口或实现类的变化。两个 原因都能引起变化，而两个职责直接是互不影响的，所以可以考虑拆分为两个接口