重修设计模式-设计原则
重修设计模式-设计原则
设计原则
设计原则是软件编码时所遵循的规则，旨在帮助开发者创建出既满足功能需求又易于维护、可扩展且美观的设计，理解设计原则可以提升代码质量、减少错误以及促进团队协作，但对设计原则的理解要灵活，不要拿原则当真理，生搬硬套会适得其反。
SOLID原则：
-
S：
单一职责原则（Single Responsibility Principle, SRP）A class or module should have a single responsibility.
一个类或者模块只负责完成一个职责。
这有助于降低系统的复杂性，提高代码的可读性和可维护性。当需求变更时，只需要修改负责该职责的类或模块即可。
-
O：
开闭原则（Open-Closed Principle, OCP）software entities (modules, classes, functions, etc.) should be open for extension , but closed for modification.
软件实体（模块、类、方法等）应该“对扩展开放、对修改关闭。
意味着软件应该通过添加新的代码来扩展，而不是通过修改现有的代码来实现，有助于保持系统的稳定性和可维护性。
-
L：
里式替换原则（Liskov Substitution Principle, LSP）Functions that use pointers of references to base classes must be able to use objects of derived classes without knowing it.
子类对象能够替换程序中父类对象出现的任何地方，并且保证原来程序的逻辑行为不变及正确性不被破坏。
里式替换和多态有点类似，但它们关注的角度不一样：多态是面向对象编程的一大特性，也是面向对象编程语言的一种语法，是一种代码实现的思路。而里式替换是一种设计原则，是用来指导继承关系中子类该如何设计的，子类的设计要保证在替换父类的时候，不改变原有程序的逻辑以及不破坏原有程序的正确性。
-
I：
接口隔离原则（Interface Segregation Principle, ISP）Clients should not be forced to depend upon interfaces that they do not use.
客户端不应该被强迫依赖它不需要的接口。其中的“客户端”，可以理解为接口的调用者或者使用者。
一个类对另一个类的依赖应该建立在最小的接口上。有助于减少接口的污染和不必要的依赖，提高系统的灵活性和可维护性。
-
D：
依赖倒置原则（Dependency Inversion Principle, DIP）High-level modules shouldn’t depend on low-level modules. Both modules should depend on abstractions. In addition, abstractions shouldn’t depend on details. Details depend on abstractions.
高层模块不要依赖低层模块，两者都应该依赖其抽象。
抽象不应该依赖细节。
细节应该依赖抽象。
有助于减少模块间的耦合度，提高系统的灵活性和可维护性。
在 Java 中的表现是：
-
模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；
-
接口或抽象类不依赖于实现类；
-
实现类依赖接口或抽象类。
举例，不符合依赖导致原则的类依赖关系：
符合后：
-
迪米特法则（Law of Demeter, LoD）
Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. Or: Each unit should only talk to its friends; Don’t talk to strangers.
每个模块只应该了解那些与它关系密切的模块的有限知识。或者说，每个模块只和自己的朋友“说话”，不和陌生人“说话”。
迪米特法则也叫最小知识原则：The Least Knowledge Principle。
不该有直接依赖关系的类之间，不要有依赖。有依赖关系的类之间，尽量只依赖必要的接口。迪米特法则希望减少类之间的耦合，让类越独立越好，缩小功能改动导致的代码改动范围，有助于代码“高内聚，低耦合”。
-
高内聚：相近的功能应该放到同一个类中。
-
低耦合：类与类之间的依赖关系简单清晰，即使两个类有依赖关系，一个类的代码改动也不会或者很少导致依赖类的代码改动
KISS原则
Keep It Simple and Stupid.
尽量保持简单。
强调设计应该保持简单，避免过度复杂。简单的设计更容易理解、维护和扩展。
YAGNI 原则
You Ain’t Gonna Need It.
你不会需要它。
在软件开发中，不要去设计当前用不到的功能；不要去编写当前用不到的代码。实际上，这条原则的核心思想就是：不要做过度设计。
DRY原则
Don’t Repeat Yourself.
不要重复你自己。
重复包括以下几种情况：
-
代码实现重复：两个方法中大部分代码相同，只有小部分差异。
看是否能抽出通用方法，但也要注意“单一职责原则”和“接口隔离原则”。
-
功能语义重复：两个方法的实现不同，但方法名语义相同。
-
执行重复：代码执行时，某一代码块执行冗余。