程序设计领域的设计模式的六大设计原则 + 合成复用原则（Composite Reuse Principle） ，都是一些很泛的思想（它们既可以指这个，也可以代指那个），无法生搬硬套，无法做到很具体的指导，我的建议是，有空多看几遍、多思考看看怎么能运用在实际项目中，在未来时保佑自己在设计程序时能联想到即可。

矛盾性的思考：
有时在面对一个复杂需求时，可能会面临满足了这个原则就会矛盾另一个原则的情况，这种就得做必要的取舍。

关于记忆的一些个人见解：
设计模式、设计原则...，我觉得都是不要去记忆它，而是通过你工作中的项目代码、网上好的项目代码，去做归纳总结、去发现一些特征。自己不断的总结提炼，我觉得这样才会形成自己的软件设计原则，硬背下来的，还是不灵活的。

Global Diagram

依赖倒置原则（依赖抽象接口，而不是具体对象）

• 它强调了高层次模块不应该依赖于低层次模块，而是应该依赖于抽象（接口）。这个原则有助于降低类之间的耦合度，提高系统的可维护性和可复用性。
• 依赖倒置原则要求我们将具体的实现类通过接口或者抽象类进行抽象，以便高层次模块不需要知道低层次模块的具体实现细节。这样，当低层次模块发生改变时，高层次模块不需要进行任何修改，只需要重新配置依赖关系即可。

单一职责原则（类、接口、方法）

• 一个类（接口、方法）只承担一个职责；
• 变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响；

开闭原则 （扩展开放，修改关闭）

• 对已经完成的程序来说，最佳的维护状态是，只对扩展开放，对修改关闭；

里氏替换原则（基类和子类之间的关系）

• 这个原则的核心思想是，如果一个类继承自另一个类，那么子类可以替换父类进行任何操作，前提是不能违反程序的原始行为。这要求子类的方法实现不能违背父类的规范和约束；
• 子类可以扩展父类的功能，但不能改变父类原有的功能；
• 只要父类出现的地方，子类就也可以出现，而且替换为子类后不会出现任何错误；

接口隔离原则（接口按照功能细分）

• 要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法；
• 核心就是：不要让用户、接口实现者去实现不相关的功能；
• 这个和单一职责原则有点重复；

最少知道原则 （类与类之间的亲疏关系）

• 最小化权限；

合成复用原则（Composite Reuse Principle）

• 尽量使用对象组合/聚合，而不是继承关系达到软件复用的目的；
• 合成或聚合可以将已有对象纳入到新对象中，使之成为新对象的一部分，因此新对象可以调用已有对象的功能；

有些编程语言就没有继承概念，只有组合、复用概念，各自的好坏有待辩证吧。