设计原则
- 单一职责原则
这个比较好理解,就是保证每个方法和类所行职责明确且唯一,如果涵盖多个职责可以考虑按职责剥离拆分,这个原则可以从方法上升到类再上升系统业务模块
- 开闭原则
理解:需求涉及改动时,对已存在的代码逻辑增加扩展类或扩展方法而不是在原有逻辑中增加if else判断,这种改动一般不会改动原有逻辑,最多把新逻辑引入现有逻辑的改动
应用:很多设计模式也是为了达到这个效果,比如责任链模式
- 接口隔离原则
“拆分非常庞大臃肿的接口称为更小的和更具体的接口,这样客户将会只需要知道他们感兴趣的接口”,类似重构中的拆分,不过这里拆分的是接口为更小的接口,从而达到接口功能的隔离性
- 里氏替换原则
维基百科得到的解释是“派生类(子类)对象可以在程式中代替其基类(超类)对象”,按这种理解子类不应该重写父类的方法或者实现已经有默认实现的接口方法,即子类要和父类已有的逻辑保持一致
- 依赖倒置原则
理解:
- 高层模块不应该依赖于低层模块,两者都应该依赖于抽象接口
- 抽象接口不应该依赖具体的实现,二具体实现应该依赖于抽象接口(面向接口编程)
应用:java实现依赖倒置的三种方式 1. 构造方法 2.setter方法 3.接口注入
- 迪米特原则(最少知道原则)
理解:对外界暴露的信息尽量的少,迪米特原则不希望类之间建立直接的联系,而是通过中介进行传输转达,这种方式可能造成一个后果:系统中存在大量的中介类,这些类存在完全是为了传递消息,增加了系统的复杂度和臃肿
应用:门面模式和中介模式都是迪米特原则的例子