本文共 1717 字，大约阅读时间需要 5 分钟。
最近感觉自己越发无知，学习不能停，写博客仍然是我觉得一个好的总结与检验学习成果的一个好方法。准备花功夫继续更新下去。最近学习计划是设计模式，希望和大家多多交流，有错误的地方请不吝赐教，期待与你共同进步。
以下是设计模式的七个核心准则：
单一原则的核心思想是：一个类应该只承担一项任务。例如，如果一个类专门用于计算优惠，那么这个类中的方法应该与优惠计算相关，完全不应该涉及商品的添加或修正。
开闭原则强调对扩展开放，对修改关闭。这意味着当系统需要增加功能时，可以通过扩展而不是修改现有代码来实现；而当需要修改现有代码时，不会对已经实现的功能产生影响。如果我们已经有一段代码，并且这段代码符合开闭原则，那么它也很容易满足其他五个准则的要求。
里氏替换原则的名称来源于Barbara Liskov女士提出的一个问题：如何度量继承关系的质量。它的核心思想是：用子类实例替换父类实例时，任何关于父类的性质都应该在子类中成立。这意味着子类不能破坏父类的行为和约束条件。
为了实现里氏替换原则，子类必须满足以下条件：
例如，如果父类定义了一个返回ArrayList的方法，那么子类只能返回更具体的集合类型，比如List。否则，父类的方法将无法正常工作。
关于里氏替换的理解，有一点需要注意：虽然父类和子类的参数可能更宽松，但返回值必须更严格。这是因为方法的约束条件由返回值来决定。如果方法返回的类型宽松化，可能会导致约束被打破。例如，父类方法返回List，子类方法返回Collection虽然看起来更灵活，但实际上可能会允许不符合父类预期的元素类型，从而破坏约束条件。
迪米特法则，也被称为“最少知道原则”，主要是建议在类之间施行细节屏蔽，也就是只向需要的对象暴露必要的信息。这样可以不让其他模块对内部的具体实现产生过多的耦合关系，从而降低耦合度。
接口隔离原则的意思是：不要让一个接口承担多于一个职责，每个接口应该只提供与其关联的功能。这个原则可以帮助我们在设计接口时更加细致划分职责，从而提高代码的可维护性和可扩展性。
接口隔离原则可以从以下两个方面来理解：
实际上，任何类都可以看作一个接口。如果一个类实现了多个接口，那么这些接口之间是否需要互相关联？答案是：它们之间是完全不相关的。所以，一个接口应该只做它自己的事情，不需要被别的接口依赖。
接口隔离原则强调的是依赖关系的透明度和避免不必要的绑定。
通过接口隔离原则，系统可以更加灵活地变化。例如，如果我们需要修改某个接口的实现，系统只需要修改实现该接口的类，而不需要修改所有使用该接口的类。
依赖倒置原则（Dependence Inversion Principle）主要是为了避免高层模块对低层模块的直接依赖，从而降低耦合度。具体来说，它的核心思想是：高层模块不应该直接依赖底层模块，而是应该通过抽象来进行通信。
依赖倒置原则可以更具体地表述为：
这个原则的本质是让模块之间的通信更加灵活，不会直接受具体实现的影响。例如，如果我们有一个支付系统，客户端不应该直接依赖于某个传输层的实现类，而是应该依赖于一个支付接口，这样客户端可以使用不同的传输实现而无需做任何修改。
虽然了解了解这些原则很有帮助，但是在实际工作中，可能需要根据具体的场景做取舍。某些情况下，可能需要放松某些原则，因为业务需求或技术限制使得完全遵守所有原则变得不现实。关键在于理解每个原则的核心思想，并在实际应用中灵活运用。
未来，我会继续深入理解和实践这些设计模式，也会更关注它们之间的相互关系和实际应用中的权衡。感谢你的关注，期待能和你一起不断进步。
转载地址：http://yerjz.baihongyu.com/