设计模式六大原则

设计原则

单一职责原则

有且仅有一个原因引起类的变更

里氏替换原则

只要父类能出现的地方，子类就可以出现，使用者不需要知道是父类还是子类 (反过来就不一定行)

• 子类必须完全实现父类的方法
  
  • 如果子类不能完整的实现父类的方法，或者父类的某些方法在子类中已经发生畸变，则建议断开父子继承关系，采用依赖，聚合，组合等关系代替继承
• 子类可以有自己的个性
  
  • 子类出现的地方，父类未必可以胜任
  • 但应避免子类的个性，一旦子类有个性，子类和父类的关系就很难调和了
• 覆盖或实现父类的方法时输入参数可以被 放大
  
  • 子类方法的参数可以大于等于父类的方法的参数 (父类方法返回值或者父类方法返回值的父类)
• 覆写或实现父类的方法时输出结果可以被 缩小
  
  • 子类方法的返回值可以小于等于父类方法返回值 (父类方法返回值或者父类方法返回值的子类)

依赖倒置原则

面向接口编程

• 高层模块不应该依赖低层模块，两者都应该依赖其抽象。
• 抽象不应该依赖细节。
• 细节应该依赖抽象。

接口隔离原则

类间的依赖应该建立在最小的接口上(适度)

迪米特原则

一个对象应该对其他对象有最少的了解

• 只和朋友交流
  
  • 朋友类:出现在成员变量，方法的输入输出参数中的类称为朋友类，而出现在方法体内部的类不属于朋友类。
  • JDK API提供的类除外
• 朋友间也是有距离的
  
  • 一个类公开的public属性或方法越多，修改时涉及的面也就越大，变更引起的风险也就越大
  • 设计时需要反复衡量，是否还可以再减少public方法和属性，是否可以加上final关键字等
• 是自己的就是自己的
  
  • 如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放置在本类中
• 谨慎使用Serializable

开闭原则

一个软件实体如类，模块和函数应该对扩展开放，对修改关闭。

一个项目的基本路径应该是这样的: 项目开放，重构，测试，投产，运维
其中重构可以对原由的设计和代码进行修改，运维尽量减少对原有代码的修改，保持历史代码的纯洁性，提高系统的稳定性

前5个原则是指导设计的工具和方法，而开闭原则才是其精神领袖。

抽象约束

• 通过接口或抽象类可以约束一组可能变化的行为，并且能够实现对扩展开放
  
  • 通过接口或抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法
  • 参数类型，引用类型尽量使用接口或者抽象类，而不是实现类
  • 抽象层尽量保持稳定，一旦确定即不允许修改

元数据控制模块行为

尽量使用源数据(配置参数)来控制程序的行为，减少重复开发。

达到极致: 控制翻转

制定项目章程

指定所有人员都必须遵守的约定

封装变化

• 将相同的变化封装到一个接口或抽象类中
• 将不同的变化封装到不同的接口或抽象类中，不应该有两个不同的变化出现在同一个接口或抽象类中

设计模式复习的读书笔记于《设计模式之禅第二版》