设计原则
单一职责原则
Single Responsibility Principle:
- A class or module should have a single reponsibility
- 一个类或者模块只负责完成一个职责(或者功能)
- 保证设计类、接口、方法时做到功能单一,权责明确。
开闭原则
Open Closed Principle:
- software entities (modules, classes, functions, etc.) should be open for extension , but closed for modification
- 软件实体(模块、类、方法等) 应该 “对扩展开放、对修改关闭”
- 模块应该在尽量不修改代码的前提下进行拓展,这就需要使用接口和抽象类来实现预期效果。
里氏替换原则
Liskov Substitution Principle:
- If S is a subtype of T, then objects of type T may be replaced with objects of type S, without breaking the program
- 子类对象(object of subtype/derived class)能够替换程序(program)中父类对象(object of base/parent class)出现的任何地方,并且保证原来程序的逻辑行为(behavior)不变及正确性不被坏
- 就是说,只要父类能出现的地方子类就可以出现,并且使用子类替换掉父类的话,不会产生任何异常或错误,使用者可能根本就不需要知道是父类还是子类。反过来就不行了,有子类的地方不一定能使用父类替换。
接口隔离原则
Interface Segregation Principle:
- Clients should not be forced to depend upon interfaces that they do not use
- 客户端不应该强迫依赖 它不需要的接口
- 类间的依赖关系应该建立在最小的接口上。 简单来说就是建立单一的接口,不要建立臃肿庞大的接口。也就是接口尽量细化,同时接口中的方法尽量少,保持接口纯洁性。
依赖反转原则(DIP)
Dependency Inversion Principle:
- 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.
- 高层模块(high-level modules)不要依赖低层模 块(low-level)。高层模块和低层模块应该通过抽象(abstractions)来互相依赖。除此 之外,抽象(abstractions)不要依赖具体实现细节(details),具体实现细节 (details)依赖抽象(abstractions)
- 程序要依赖于抽象接口,不要依赖于具体实现。简单的说就是要求对抽象进行编程,不要对实现进行编程,这样就降低了客户与实现模块间的耦合。
KISS 原则和 YAGNI 原则
KISS 原则
Keep It Simple and Stupid
- 尽量保持简单
YAGNI 原则
You Ain’t Gonna Need It
- 不要做过度设计
DRY 原则
Don’t Repeat Yourself
迪米特法则
Law of Demeter / The Least Knowledge Principle
- 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.
- 不该有直接依赖关系的类之间,不要有依赖;有依赖关系的类之间,尽量只依赖必要的 接口(也就是定义中的“有限知识”)
- 一个软件实体应当尽可能少地与其它实体发生相互作用。迪米特法则的初衷在于降低类之间的耦合。
提高代码复用性
- 减少代码耦合
- 满足单一职责原则
- 模块化
- 业务与非业务逻辑分离
- 通用代码下沉
- 继承、多态、抽象、封装
- 应用模板等设计模式