🧑‍💻作者名称：DaenCode 🎤作者简介：啥技术都喜欢捣鼓捣鼓，喜欢分享技术、经验、生活。 😎人生感悟：尝尽人生百味，方知世间冷暖。 📖所属专栏：设计模式

@[toc]

🌟单一职责原则

• 核心思想：任何一个软件模块中，应该有且只有一个被修改的原因。
• 例子描述：功能性函数全都放到一个Service类里面，违反了单一职责原则。
• 优点：职责越单一，被修改的原因就越少，类的复杂度降低、可读性提高、可维护性提高、扩展性提高、降低了变更引起的风险。
• 缺点：如果类一味追求单一职责，有时会造成类的大爆炸，不过接口和方法肯定要遵循这个原则。
• 注意：单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”和“变化原因”都是不可以度量的，因项目和环境而异。

🌟依赖倒置原则

• 核心思想：高层模块不应该依赖底层模块，二者都该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
• 说明：高层模块就是调用端，低层模块就是具体实现类。抽象就是指接口或抽象类。细节就是实现类。
• 通俗来讲：依赖倒置原则的本质就是通过抽象（接口或抽象类）使个各类或模块的实现彼此独立，互不影响，实现模块间的松耦合。模块之间交互应该依赖抽象，而非实现。
• 优点：大幅提高了可扩展性，降低耦合度，使代码层次更加清晰。 如果要切换数据库

DbService dbService = new MysqlService(); //改成NoSqlService, OracleService即可

🌟开闭原则

• 核心思想：软件实体应该对扩展开放，对修改关闭。
• 说明：对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展以适应新的情况。对修改关闭，意味着类的设计一旦完成，就可以独立完成工作，而不要对其进行任何修改。

🌟接口隔离原则

• 核心思想：多个特定的接口要好于一个宽泛用途的接口
• 通俗来讲：建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。
• 优点：将外部依赖减到最少。你只需要依赖你需要的东西。这样可以降低模块之间的耦合。
• 注意：
  • 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。
  • 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事

🌟迪米特法则（Law of Demeter）

• 核心思想：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。 注意：
• 第一: 从被依赖者的角度来说：只暴露应该暴露的方法或者属性。
• 第二: 从依赖者的角度来说：只依赖应该依赖的对象。

🌟里氏替换原则

• 核心思想：程序中的父类型都应该可以正确地被子类替换。
• 原理：继承复用的基石，只有当子类可以替换掉父类，且软件的功能不受到任何影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。
• 通俗来讲：只要有父类出现的地方，都可以使用子类来替代。子类出现的地方,不能使用父类来替代。例如：我喜欢动物，那我一定喜欢狗，因为狗是动物的子类；但是我喜欢狗，不能据此断定我喜欢动物，因为我并不喜欢老鼠，虽然它也是动物。
• 优点：代码共享，减少创建类的工作量。提高代码的重用性，可扩展性。
• 缺点：继承是侵入性的。只要继承，就必须拥有父类的所有属性和方法；增强了耦合性。当父类的常量、变量和方法被修改时，需要考虑子类的修改
• 注意：如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，则建议断开父子继承关系 采用依赖、聚合、组合等关系代替继承。
• 最佳实践：我们最好将父类定义为抽象类，并定义抽象方法，让子类重新定义这些方法，当父类是抽象类时候，父类不能实例化。

🌟总结

• 单一职责原则：提高代码实现层的内聚度，降低实现单元彼此之间的耦合度
• 开闭原则：提高代码实现层的可扩展性，提高面临改变的可适应性，降低修改代码的冗余度
• 里氏替换原则：提高代码抽象层的可维护性，提高实现层代码与抽象层的一致性
• 接口隔离原则：提高代码抽象层的内聚度，降低代码实现层与抽象层的耦合度，降低代码实现层的冗余度
• 依赖倒置原则：降低代码实现层由依赖关系产生的耦合度，提高代码实现层的可测试性
• 迪米特法则：一个对象应该对其他对象保持最少的了解。尽量降低类与类之间的耦合。