1.开闭原则:

对扩展开放,对修改关闭

也就是说在增加新特性的时候最好考虑通过扩展已有系统的方式来实现需求的变化,而不是通过直接通过修改系统已有源码的方式。

也就是说一旦程序开发完成,程序中一个类的实现只应该因为错误而修改,新的或者改变的特性应该通过新建不同的类的实现,新建的类可以通过继承的方式来重用已有的代码。

开闭原则的必要性:

因为一个已有的系统一般都是事先经过千万次测试的稳定系统,如果直接对这些稳定系统进行修改,很有可能直接影响到原有系统的稳定性。

同时如果部分系统有测试用例的情况下,每修改一个代码有可能需要修改大量的用例代码

而通过继承可以保证不影响原有系统稳定性的情况下实现变化,这种情况下只需对新增变化进行各项测试即可。

如何使用:

通过抽象类或者接口对可扩展性作适当的限定,这其实就是为了限定整个系统的可扩展范围。

对象引用避免使用具体的实现类,尽可能使用接口或者抽象类。这样可以保证整个系统的可扩展性。(里氏替换原则)

抽象层必须保持稳定。并且预知了所有可能的扩展,在任何扩展下都不会变化。

2.里氏替换原则

所有父类能够出现的地方,之类都应该可以出现。

用在实际就是在类中调用其他类的时候尽可能使用父类或者接口。

里氏替换原则的核心思想就是通过抽象建立规范,具体的实现在运行时替换掉抽象,从而实现功能扩展。

3.依赖倒置原则

模块之间的依赖关系需要通过抽象发生,实现类之间不发生直接的依赖关系。其依赖关系是通过接口或者抽象类来产生的。

实现细则:

每个类都应该有接口或者抽象类,或者两者都存在

变量的类型尽量是接口或者是抽象类

任何类都不允许从具体类中派生

一般使用接口定义公开的属性和方法,抽象类负责准确地实现业务逻辑。

比如下图所示通过AbstractClass1 和2 建立起依赖关系。而不是通过具体的之类来直接建立关系。

4.接口隔离原则

类之间的依赖关系应该建立在最小的接口上,在项目中需要按照职责将臃肿的接口拆封成更小的和更具体的接口,这样客户只需要知道他们感兴趣的方法,

把不需要的接口剔除掉,最好做到一个接口只服务于一个子模块或者业务逻辑。

5.迪米特法则

一个类应该对自己需要耦合或者调用的类知道得最少。

6. 单一职责原则

接口或者类,尽量要做到单一职责,类的设计尽量要做到只有一个原因引起变化,而对于方法则需要满足一个方法尽可能只做一件事情。

Contents
  1. 1. 1.开闭原则:
  2. 2. 2.里氏替换原则
  3. 3. 3.依赖倒置原则
  4. 4. 4.接口隔离原则
  5. 5. 5.迪米特法则
  6. 6. 6. 单一职责原则