设计原则
一、单一职责原则(Single Responsibility Principle,SRP)
定义:
应该有且仅有一个原因引起类的变更
一个接口或类只有一个原因引起变化，也就是一个接口或类只有一个职责，它就负责一件事情
优点:
- 类的复杂性降低,实现什么职责都有清晰明确的定义
- 可读性提高
- 可维护性提高
- 变更引起的风险降低,变更是必不可少的,如果接口的单一职责做的好,一个接口修改只对相应的实现类有影响,对其他接口无影响,对系统的扩展性、维护性都有非常大的帮助
二、里式替换原则(Liskov Substitution Principle,LSP)
定义:
所有引用基类的地方必须能透明地使用其子类的对象(父类可以替代子类,子类不能替代父类)
继承机制的优点:
- 代码共享,减少创建类的工作量,每个类都拥有父类的方法和属性
- 提高代码的重用性
- 子类可以形似父类,但又异于父类
- 提高代码的可扩展性,覆写 父类方法
- 提高产品或项目的开放性
继承机制的缺点：
- 继承是侵入性的,只要有继承，就必须拥有父类的所有属性和方法
- 降低代码的灵活性,子类必须拥有父类的属性和方法
- 增强了耦合性,当父类的常量、变量和方法修改时,需要考虑子类的修改,而且缺乏规范的环境下，这种修改可能会带来非常糟糕的结果——大段代码需要重构
注意:
在类中调用其他类时务必要使用父类或接口,如果不能使用父类或接口,则说明类的设计已经违背了LSP原则
如果子类不能完成的实现父类的方法,或者父类的某些方法在子类中已经发生了"畸变",则建议断开父子继承关系,采用依赖、聚集、组合灯关系代替继承
覆盖或实现父类的方法时输入参数可以被放大,覆写或实现父类方法时输出结果可以被缩小
三、依赖倒置原则(Dependence Inversion Principle,DIP)
定义:
- 高层模块不应该依赖低层模块,两者都应该依赖其抽象(模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的)
- 抽象不应该依赖细节(接口或抽象类不依赖于实现类)
- 细节应该依赖抽象(实现类依赖接口或抽象类)
面向接口编程(OOD)
注意:
依赖倒置原则的本质就是通过抽象(接口或抽象类)使各个类或模块的实现彼此独立,不互相影响,实现模块间的松耦合
- 每个类尽量都有接口或抽象类,或者抽象类和接口两者都具备
- 变量的表面类型尽量是接口或者是抽象类
- 任何类都不应该从具体类派生(不是绝对的,不超过2层的继承都可以接受)
- 尽量不要覆写基类的方法
- 结合里式替换原则使用
四、接口隔离原则
定义：
接口分为两种:
- 实例接口:java 的类也是一种接口
- 类接口:interface 定义的接口
- 客户端不应该依赖它不需要的接口
- 类间的依赖关系应该建立在最小的接口上
保证接口的纯洁性:
- 接口要尽量小(根据接口隔离原则拆分接口时,首先必须满足单一职责原则)
- 接口要高内聚
- 定制服务
- 接口的设计是有限度的
注意:
- 一个接口只服务于一个子模块或业务逻辑
- 通过业务逻辑压缩接口中的 public 方法,接口时常去回顾,尽量让接口达到满身筋骨
- 已经被污染了的接口，尽量去修改,若变更的风险较大,则采用适配器模式进行转化处理
- 了解环境,拒绝盲从,环境不同,接口拆分标准就不同,深入了解业务逻辑
五、迪米特法则(Law of Demeter,LoD)
定义:
一个对象应该对其他对象有最少的了解,一个类应该对自己需要耦合或调用的类知道的最少
- 只和朋友交流
- 朋友间是有距离的
- 自己的就是自己的(如果一个方法放在本类中,既不增加类间关系,也对本类不产生负面影响,那就放置在本类中)
- 谨慎使用 Serializable 接口
六、开闭原则
一个软件实体如类、模块和函数应该对扩展开放,对修改关闭
浙公网安备 33010602011771号