设计模式是站在设计原则的基础之上的，所以在学习设计模式之前，有必要对这些设计原则做一下了解。 ### ## **单一职责原则** ### ### 要领 ### **一个类只负责一个功能领域中的相应职责**，就一个类而言，应该只有一个引起它变化的原因，是实现高内聚、低耦合的指导方针； ### ### 解释 ### #### 高内聚： ### 尽可能类的每个成员方法只完成一件事(最大限度的耦合) 模块内部的代码，相互之间的联系越强，内聚就越高，模块的独立性就越好 **比如操作redis缓存，我们可以将一切操作redis缓存的操作都放到同一个类当中，这样就实现了高内聚的原则** ### #### 低耦合： ### 减少类内部，一个成员方法调用另一个成员方法，不要有牵一发动全身的现象出现，**比如类内部方法和方法之间的操作，我们可以通过中间方法去操作，避免直接调用彼此，因为一个方法就是一个功能，通过中间方法去操作虽然多写了一个方法但是让彼此两个方法解耦**。 ### 类的内部方法之间的调用是无法完全避免耦合的。即使是在同一个类内部，一个方法调用另一个方法，也会存在一定程度的耦合。因为这种调用关系意味着方法之间有依赖关系，修改一个方法可能会影响到另一个方法的行为。 ### 然而，在设计类时，可以尽量减少方法之间的直接调用，从而降低耦合度。可以采用一些设计模式和原则，如**单一职责原则**、依赖倒置原则、以及面向接口编程等，来降低类的内部方法之间的耦合度，提高代码的灵活性和可维护性 ### ## **开闭原则** ### 对扩展开放，对修改关闭，**在程序需要进⾏拓展的时候，不能去修改原有的代码，实现⼀个热插拔的效果** ### ## **⾥⽒替换原则LSP** ### 任何基类可以出现的地⽅，⼦类⼀定可以出现； **在程序中尽量使⽤基类类型来对对象进⾏定义，⽽在运⾏时再确定其⼦类类型，⽤⼦类对象来替换⽗类对象；** 比如我们在控制器层调用Service的时候都是使用Service的接口，在运行时会去找ISysMenuService接口的实现类里面的方法:  里氏替换原则（Liskov Substitution Principle，简称LSP）是面向对象设计中的一个重要原则，由计算机科学家Barbara Liskov提出。该原则要求，任何基类（父类）可以被其子类（派生类）所替换，而程序仍然能够正确地工作。换句话说，子类必须能够替换其父类而不影响程序的正确性。 ### **LSP的好处主要体现在以下几个方面**： 1. **提高代码的可维护性：** 遵循LSP可以确保子类可以完全替代父类，从而使得代码更加灵活和可扩展。这样一来，**如果需要修改或扩展系统的功能，只需添加新的子类或修改现有的子类，而不需要对现有的代码进行大规模的修改，提高了代码的可维护性**。 2. **增强代码的可扩展性：** 符合LSP的设计使得系统更容易扩展。**由于子类可以替换父类，因此可以在不影响原有代码的情况下引入新的子类来扩展系统的功能，而不必改变现有的代码**。 3. **提高代码的可读性和可理解性：** 符合LSP的设计通常会使得代码结构更加清晰和直观。通过合理的类继承关系，使得代码更易于理解和阅读。 4. **减少错误：** 符合LSP的设计可以减少因为类之间的替换而导致的错误。如果一个子类不能完全替换父类，那么在使用该子类替换父类的情况下可能会导致意料之外的错误。 总的来说，遵循里氏替换原则可以带来更加灵活、可维护和可扩展的代码，提高软件系统的质量和可靠性。 ### ## **依赖倒转原则** ### 是开闭原则的基础，针对接⼝编程，依赖于抽象⽽不依赖于具体； **⾼层模块不应该依赖低层模块，⼆者都应该依赖其抽象；** ### 依赖倒转原则（Dependency Inversion Principle，简称DIP）是面向对象设计中的一个重要原则，它指导我们如何设计类之间的依赖关系，以实现代码的灵活性、可扩展性和可维护性。依赖倒转原则是开闭原则的基础，是实现开闭原则的重要手段之一。 ### 依赖倒转原则的核心思想可以归纳为以下几点： 1. **针对接口编程：** **程序设计应该依赖于抽象接口，而不是具体实现**。抽象接口可以是**接口（Interface）或抽象类（Abstract Class），而具体实现则是实现了这些接口或继承了这些抽象类的具体类**。 2. **高层模块不应该依赖于低层模块：** 在传统的程序设计中，通常是高层模块依赖于低层模块，比如业务逻辑层依赖于数据访问层。而依赖倒转原则提倡的是反向依赖关系，**高层模块和低层模块都应该依赖于抽象**。 3. **抽象不应该依赖于细节：** **抽象接口或抽象类不应该依赖于具体的实现细节，而是应该由具体的实现细节来依赖抽象**。这意味着具体的实现细节可以灵活地替换或者扩展，而不影响高层模块的设计和实现。 4. **细节应该依赖于抽象：** **具体的实现细节应该依赖于抽象接口或抽象类，这样可以保证系统的稳定性和可靠性**。 总的来说，依赖倒转原则通过引入抽象层，**将高层模块与低层模块之间的依赖关系转化为对抽象的依赖，从而降低模块之间的耦合度，提高系统的灵活性和可扩展性**。 **依赖倒转原则有助于更好地利用多态进行开发。依赖倒转原则鼓励使用抽象类型而不是具体类型，这使得代码更具多态性**。 通过依赖抽象而不是具体实现，我们可以在不修改现有代码的情况下轻松地引入新的实现，并利用多态来替换现有的实现。这样，代码更容易扩展和维护，并且可以更灵活地适应变化。 总之，依赖倒转原则为利用多态性提供了良好的基础，有助于编写更加灵活、可扩展和可维护的代码。 ### **高层模块和低层模块的解释** ### 1. **高层模块：** 高层模块通常指的是系统中较为抽象和通用的模块，它们实现了系统的核心业务逻辑或者提供了系统的核心功能。高层模块往往是用户接口、业务逻辑、应用逻辑等层面的模块。在软件设计中，高层模块通常会依赖于低层模块，而不会暴露太多的实现细节。 ### 2. **低层模块：** 低层模块通常指的是系统中较为具体和底层的模块，它们实现了系统的基础功能或者提供了系统的基础支持。低层模块往往是数据访问、数据存储、与外部系统交互等层面的模块。在软件设计中，低层模块通常会被高层模块所依赖，提供具体的实现细节。 ### ## **接口隔离原则** ### 客户端不应该依赖那些它不需要的接⼝ **使⽤多个隔离的接⼝，⽐使⽤单个接⼝要好，降低类之间的耦合度** ### **接口隔离原则**（Interface Segregation Principle，ISP）是面向对象设计中的一个原则，主要强调“客户端不应该被强迫依赖它不需要的接口”。这意味着一个类对另一个类的依赖应该建立在最小的接口上。 简而言之，接口隔离原则要求将接口尽可能地细化，不要设计臃肿庞大的接口，而是应该将大接口拆分成多个小接口，让客户端只依赖它们需要的接口。 接口隔离原则的主要目标包括： 1. **将接口粒度细化：将大接口拆分成多个小接口，每个接口只包含客户端需要的方法**。 2. **避免臃肿的接口：减少接口中的方法数量，避免接口中存在过多的方法，尽量保持接口的单一性。** 3. 提高灵活性：通过接口隔离原则，可以提高系统的灵活性，使得系统更容易扩展、修改和维护。 4. 降低耦合度：遵循接口隔离原则可以降低类与类之间的耦合度，减少对不相关接口的依赖，提高系统的内聚性。 接口隔离原则的实践方法包括： 1. **将大接口拆分成多个小接口，每个接口只包含特定功能相关的方法**。 2. **根据客户端的需求设计接口，避免设计过多的通用接口。** 3. **使用接口继承和实现来实现接口隔离，避免使用过多的方法在同一个接口中。** 4. 定期审查和重构接口设计，确保接口的单一职责和高内聚性。 总之，接口隔离原则是面向对象设计中的重要原则，通过将大接口拆分成多个小接口，可以提高系统的灵活性、降低耦合度，同时也更好地符合单一职责原则。 ### **比如实现一个功能本身只需要实现A这个interface接口里面的2个抽象方法，但是你在A接口里面写了一大堆的其他用不到的抽象方法就是不合理的，我用不到的就不要写，哪怕多写几个接口进行拆分，哪怕多写几个接口的子接口来继承去实现；** ### ## **迪⽶特法则** ### 最少知道原则，⼀个实体应当尽量少地与其他实体之间发⽣相互作⽤，使得系统功能模块相对独⽴ 类之间的耦合度越低，就越有利于复⽤，⼀个处在松耦合中的类⼀旦被修改，不会对关联的类造成太⼤波及 通过引⼊⼀个合理的第三者来降低现有对象之间的耦合 ### 迪米特法则（Law of Demeter，LoD），又称最少知识原则（Principle of Least Knowledge，PLK），是面向对象设计中的一个原则，主要强调“一个对象应该对其他对象有最少的了解”。简单来说，一个对象应该只与其直接的朋友通信，而不要与陌生的对象通信。 具体来说，迪米特法则有以下几个要点： 1. 一个对象应当对其他对象有限制的了解，它只和朋友对象交流，不和陌生对象交流。**所谓的“朋友”是指：当前对象本身、当前对象的成员对象、方法的参数对象、方法内部创建的对象等**。 2. **避免在方法内部直接访问其他对象的内部属性，而应该通过访问器（getter）来获取**。 3. **避免在方法内部直接调用其他对象的方法，而应该通过当前对象的成员对象来调用**。 4. 尽量降低类之间的耦合度，每个类尽可能独立存在，减少类之间的直接依赖关系。 迪米特法则的目的是降低系统的耦合度，提高系统的灵活性和可维护性。通过减少对象之间的直接依赖关系，可以使系统更容易扩展和修改，同时也更容易进行单元测试和重构。 在实际应用中，可以通过以下方法来遵循迪米特法则： 1. **尽量将方法的访问权限设置为私有或受保护，限制方法的调用范围**。 2. **尽量将类的成员属性设置为私有或受保护，并通过访问器来访问**。 3. **尽量减少对象之间的直接依赖关系，通过依赖注入、接口隔离等设计模式或者参数传递来实现**。 4. 定期审查和重构代码，确保符合迪米特法则，降低系统的耦合度。 总之，迪米特法则是面向对象设计中的重要原则，通过限制对象之间的直接交流，可以降低系统的耦合度，提高系统的灵活性和可维护性。 ### **关于迪⽶特法则的精准介绍** ### 一个对象应该对其他对象保持最少的了解 类与类关系越密切，耦合度越大 迪米特法则(Demeter Principle)又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的public 方法，不对外泄露任何信息 **迪米特法则还有个更简单的定义：只与直接的朋友通信 直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖，关联，组合，聚合等。其中，我们称出现成员变量，方法参数，方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部** ### 具体的一个迪米特法则可参考地址：https://www.cnblogs.com/snail-learn-code/p/14361559.html