重修设计模式-设计原则

设计原则

设计原则是软件编码时所遵循的规则，旨在帮助开发者创建出既满足功能需求又易于维护、可扩展且美观的设计，理解设计原则可以提升代码质量、减少错误以及促进团队协作，但对设计原则的理解要灵活，不要拿原则当真理，生搬硬套会适得其反。

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.

不要重复你自己。

重复包括以下几种情况：

代码实现重复：两个方法中大部分代码相同，只有小部分差异。

看是否能抽出通用方法，但也要注意"单一职责原则"和"接口隔离原则"。
功能语义重复：两个方法的实现不同，但方法名语义相同。
执行重复：代码执行时，某一代码块执行冗余。