一、设计原则的核心思想
- 找出应用中可能需要变化之处，将其独立出来，无需与那些不需要变化的代码混在一起
- 针对接口编程，而不是针对实现编程
- 为了降低耦合
二、七大设计原则
1.单一职责原则SRP(Single Responsibility Principle)
单一职责原则表示一个模块的组成元素之间的功能相关性。从软件变化的角度来看，就一个类而言，应该仅有一个让它变化的原因；通俗地说，即一个类只负责一项职责。
2.接口隔离原则ISP(Interface Segregation Principle)
客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
3.依赖倒转（倒置）原则DIP(Dependence Inversion Principle)
高层模块不应该依赖低层模块，二者都应该于抽象。进一步说，抽象不应该依赖于细节，细节应该依赖于抽象。其核心思想就是面向接口编程。
4.里氏替换原则LSP(Liskov Substitution Principle)
所有引用基类（父类）的地方必须能透明地使用其子类的对象。 通俗的说，子类可以扩展父类功能，但不能改变父类原有功能。核心思想：继承。
5.开闭原则OCP(Open-Closed Principle)
一个软件实体如类、模块和函数应该对扩展开放（对提供方），对修改关闭（对使用方）。用抽象构建框架，用实现扩展细节。
6.迪米特法则LOD(Law Of Demeter)
一个对象应该对其他对象有最少的了解；又称最少知识原则（Least Knowledge Principle, LKP），其意义在于降低类之间的耦合。
7.组合/聚合复用原则 CARP(Composite/Aggregate Reuse Principle)
要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。
七大设计原则的优缺点
原则 | 优点 | 缺点 |
SRP | 1 降低了类的复杂度，逻辑比多项职责简单 2 提高了代码的可读性，提高了系统的可维护性 | 1 逻辑及职责都足够简单的情况下就显得繁琐 |
ISP | 1 接口越细，越灵活，有更好应变性，可维护性 | 1 接口过细，以造成类接口"膨胀"，增加系统的复杂性 |
DIP | 1 降低类之间的耦合性 2 提高系统的稳定性 3 降低修改程序造成的风险 4 可以提高代码的可读性和可维护性 | 1 可能使用对象工厂，可以提高代码的可读性和可维护性 2 某些具体类可能是相当稳定的，不会发生变化，为此没有必要进行抽象 |
LSP | 1 代码重用，减少创建类的成本 2 易维护易扩展 | 1 破坏封装，具有侵入性，子父类间紧密耦合 2 子类不能改变父类 可能造成子类代码冗余、灵活性降低 |
OCP | 1 可提高系统的可复用性和可维护性 | 1 容易引起类爆炸 |
LOD | 1 降低了类之间的耦合度，提高了模块的相对独立性 2 由于亲合度降低，从而提高了类的可复用率和系统的扩展性 | 1 过分的使用迪米特原则，会产生大量这样的中介和传递类，导致系统复杂度变大 |
CARP | 1 维持了类的封装性。因为成分对象的内部细节是新对象看不见的，所以这种复用又称为“黑箱”复用 2 新旧类之间的耦合度低。这种复用所需的依赖较少，新对象存取成分对象的唯一方法是通过成分对象的接口 3 复用的灵活性高。这种复用可以在运行时动态进行，新对象可以动态地引用与成分对象类型相同的对象 | 1 需要许多中间类或接口，存在类爆炸风险，降低系统的可读性和可维护性 |
以上内容参考了网上一些博主的内容进行汇总和总结，如有错误，欢迎大家指正，同时对各位博主特此表示感谢！本文就不一一列出，如有侵权，还请谅解。
个人推荐
本文暂时没有评论，来添加一个吧(●'◡'●)