目录

单一职责原则（Single Responsibility Principle, SRP）：

单一职责原则（Single Responsibility Principle, SRP）概念：

单一职责原则（Single Responsibility Principle, SRP）的例子：

开放封闭原则（Open-Closed Principle, OCP）：

开放封闭原则（Open-Closed Principle, OCP）概念：

开放封闭原则（Open-Closed Principle, OCP）的例子？

里氏替换原则（Liskov Substitution Principle, LSP）：

里氏替换原则（Liskov Substitution Principle, LSP）概念：

里氏替换原则（Liskov Substitution Principle, LSP）的例子：

依赖倒置原则（Dependency Inversion Principle, DIP）：

依赖倒置原则（Dependency Inversion Principle, DIP）概念：

依赖倒置原则（Dependency Inversion Principle, DIP）的例子：

接口隔离原则（Interface Segregation Principle, ISP）：

接口隔离原则（Interface Segregation Principle, ISP）概念：

接口隔离原则（Interface Segregation Principle, ISP）的例子：

合成聚合复用原则（Composite Reuse Principle, CRP）：

合成聚合复用原则（Composite Reuse Principle, CRP）：

合成聚合复用原则（Composite Reuse Principle, CRP）的例子：

迪米特法则（Law of Demeter, LoD）：

迪米特法则（Law of Demeter, LoD）：

迪米特法则（Law of Demeter, LoD）的例子：

违反迪米特法则的问题主要有两个方面：

单一职责原则（Single Responsibility Principle, SRP）：

单一职责原则（Single Responsibility Principle, SRP）概念：

类的功能要单一，不能包罗万象，跟杂货铺似的；

单一职责原则规定一个类应该只有一个改变的原因。这意味着一个类应该只承担一个职责或任务。例如，如果你有一个处理报告的类，它应该专注于如何生成报告，而不应该同时负责获取报告的数据或保存报告。获取和保存数据应该由其他类负责。

当一个类的职责过多时，这个类会变得复杂，且难以维护和修改。如果一个职责发生变化，可能会影响到其他职责的实现。将职责拆分到不同的类中，可以降低类的复杂性，提高代码的可读性和可维护性。

单一职责原则（Single Responsibility Principle, SRP）的例子：

假设你有一个 Employee 类，这个类负责处理员工的薪水计算和打印薪水单。这样的设计违反了单一职责原则。为了遵循这个原则，你可以创建一个新的 PayCalculator 类来处理薪水计算，创建一个 PayPrinter 类来处理薪水单的打印。

开放封闭原则（Open-Closed Principle, OCP）：

开放封闭原则（Open-Closed Principle, OCP）概念：

开放封闭原则规定软件实体（类、模块、函数等等）应该对扩展开放，对修改封闭。这意味着你应该能够添加新功能，而不需要修改现有代码；

开放封闭原则（Open-Closed Principle, OCP）的例子？

例如，你有一个渲染形状的函数，它根据形状的类型调用不同的渲染方法。当你需要添加新的形状类型时，你可能需要修改这个函数。这违反了开放封闭原则。你可以通过使用多态来满足这个原则：定义一个形状接口，每个形状类都实现这个接口的渲染方法。这样，渲染函数就可以接受任何实现了形状接口的对象，不需要修改代码就可以添加新的形状类型；

假设你有一个 GraphicEditor 类，这个类包含一个方法 drawShape，该方法根据传入的形状类型决定调用哪个绘制方法。如果你想添加新的形状，那么就需要修改 GraphicEditor 类的代码。为了遵循开放封闭原则，你可以定义一个 Shape 接口，然后让每种形状的类都实现这个接口的 draw 方法。这样，GraphicEditor 类就可以接受任何形状对象，不需要修改代码就可以支持新的形状；

Collections.sort() 方法，这就是基于策略模式，遵循开闭原则的，你不需为新的对象修改sort() 方法，你需要做的仅仅是实现你自己的Comparator 接口；

里氏替换原则（Liskov Substitution Principle, LSP）：

里氏替换原则（Liskov Substitution Principle, LSP）概念：

里氏替换原则规定子类型必须能够替换它们的基类型，而不会导致任何错误或异常；

这意味着如果一个类继承自一个基类，那么不应该改变基类的行为；

子类可以替换父类出n现在父类能够出现的任何地方；比如你能代表你爸去你姥姥家干活；哈哈~~

里氏替换原则（Liskov Substitution Principle, LSP）的例子：

假设你有一个 Bird 类和一个 Penguin 类继承自 Bird 类。Bird 类有一个 fly 方法，但是 Penguin 类不能飞。这样的设计违反了里氏替换原则，因为你不能在需要 Bird 类的地方使用 Penguin 类。为了遵循这个原则，你可以将 fly 方法移出 Bird 类，创建一个 FlyingBird 类继承自 Bird 类并包含 fly 方法，然后让需要飞的鸟类继承自 FlyingBird 类；

例如，你有一个Rectangle类，它有width和height两个属性。你创建了一个Square类继承自Rectangle，并且重写了width和height的设置器（setter），使它们总是设置为相同的值。这违反了里氏替换原则，因为Square改变了Rectangle的行为。当你在需要使用Rectangle的地方使用Square时，可能会导致错误。

依赖倒置原则（Dependency Inversion Principle, DIP）：

依赖倒置原则（Dependency Inversion Principle, DIP）概念：

依赖倒置原则规定高层模块不应该依赖于低层模块，二者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。

依赖倒置原则（Dependency Inversion Principle, DIP）的例子：

例如，如果你有一个音频播放器类，它依赖于一个MP3音频源类，你可以定义一个音频源接口，让MP3音频源类实现这个接口。然后，音频播放器类就可以依赖于音频源接口，而不是MP3音频源类。这样，音频播放器类就不需要知道音频源的具体实现，只需要知道它如何提供音频数据；

假设你有一个 TextEditor 类，这个类依赖于一个具体的 FileReader 类来读取文件。这样的设计违反了依赖倒置原则，因为 TextEditor 类直接依赖于具体的 FileReader 类。为了遵循这个原则，你可以创建一个 Reader 接口，让 FileReader 类实现这个接口，然后让 TextEditor 类依赖于 Reader 接口；

接口隔离原则（Interface Segregation Principle, ISP）：

接口隔离原则（Interface Segregation Principle, ISP）概念：

接口隔离原则规定客户端不应该依赖于它们不使用的接口。这意味着你应该将大的接口拆分成一组小的接口，每个接口只包含一部分客户端需要的方法。

接口隔离原则（Interface Segregation Principle, ISP）的例子：

你有一个处理文档的接口，它有打开、保存、打印、预览和关闭等方法。但是有一些客户端可能只需要打开和保存文档，而不需要打印和预览。这个接口对于这些客户端来说就太大了；你可以将这个接口拆分成几个小的接口，比如一个只包含打开和保存方法的接口，一个只包含打印和预览方法的接口；

假设你有一个 Worker 接口，这个接口包含 work 和 eat 方法。Robot 类实现了 Worker 接口，但是 Robot 类不能吃。这样的设计违反了接口隔离原则，因为 Robot 类被强制实现了它不需要的 eat 方法。为了遵循这个原则，你可以将 Worker 接口分解为 Workable 和 Eatable 接口，然后让 Robot 类只实现 Workable 接口；

合成聚合复用原则（Composite Reuse Principle, CRP）：

合成聚合复用原则（Composite Reuse Principle, CRP）：

这个原则强调的是类的复用应该通过它的成员（尤其是它的对象成员）来实现，而不是通过继承关系。继承关系通常导致父类和子类之间的强耦合，使得父类的改变可能会影响到子类，而且继承通常会导致类的设计和实现过于复杂；

合成聚合复用原则（Composite Reuse Principle, CRP）的例子：

记住：任何时候都不要继承工具类，工具是可以拥有并可以使用的，而不是拿来继承的；

假设你有一个 Person 类，这个类通过继承 Walker 类和 Talker 类来获取行走和说话的能力。这样的设计违反了合成聚合复用原则，因为 Person 类通过继承而非包含成员对象的方式获取了额外的功能。为了遵循这个原则，你可以创建 Walker 和 Talker 对象作为 Person 类的成员；

例如，假设我们有一个Bird类和一个Fly类。如果我们想创建一个能飞的鸟，应该将Fly类作为Bird类的一个成员，而不是让Bird类继承Fly类。这样，如果我们想要一个不会飞的鸟，我们就可以不包含Fly类，而不需要修改Bird或Fly类的代码；

迪米特法则（Law of Demeter, LoD）：

迪米特法则（Law of Demeter, LoD）：

迪米特法则，又称最少知识原则，是一种用来降低类之间耦合度的设计原则。这个原则规定一个对象应当对其他对象有最少的了解，也就是说，一个类只需要与直接交互的类通信，不必关心它们与其他类之间的交互；

迪米特法则（Law of Demeter, LoD）的例子：

例如，假设我们有一个Car类，这个类有一个Engine成员和一个start方法。在start方法中，我们需要启动发动机。按照迪米特法则，Car类不应该直接操作发动机的内部，而是应该通过Engine类的方法来启动发动机；

假设你有一个 Computer 类，这个类有一个 start 方法，这个方法需要访问 PowerSupply 类的 getVoltage 方法来检查电压是否正常，然后访问 Cpu 类的 run 方法来启动 CPU。这样的设计违反了迪米特法则，因为 Computer 类直接访问了 PowerSupply 类和 Cpu 类的内部方法。为了遵循这个原则，你可以在 PowerSupply 类和 Cpu 类中添加一个 checkAndRun 方法，让这个方法负责检查电压并启动 CPU。这样，Computer 类就只需要调用 checkAndRun 方法，而不需要了解 PowerSupply 类和 Cpu 类的内部实现；

违反迪米特法则的问题主要有两个方面：

• 耦合度增加：
  • 如果一个类开始直接与深层的依赖对象交互，这会导致类之间的耦合度增加。在上述例子中，Car 类和 Piston 类之间形成了直接的依赖关系，这意味着如果 Piston 类的实现发生了变化，Car 类可能需要修改代码来适应这个变化；
• 代码的可读性和可维护性降低：
  • 迪米特法则要求类只和直接依赖对象进行交互，这可以使代码的结构更清晰，更容易理解。如果一个类开始直接交互深层的依赖对象，那么这个类的代码将会变得复杂且难以理解，这也会降低代码的可读性和可维护性；