在应用的开发过程中，最难的不是完成应用的开发工作，而是在后续的升级、维护中让应用系统能够拥抱变化。拥抱变化也就是意味着在满足需求且不破坏系统稳定性的前提下保持高可扩展性、高内聚、低耦合，在经历了各版本的变更之后依旧保持清晰、灵活、稳定的系统架构。
虽然在实际的应该开发中，要饱受产品的折磨和摧残、需要在极其有限的研发时间里完成功能、上线。但是我们仍需尽量保持遵循面向对象的六大设计原则，这才能让我们不必在各种需求的苦海中挣扎。
1.单一责任原则
定义：就一个类而言，应该只有一个引起变化的原因。
优点：低耦合
缺点：责任界限比较难划分
总结：在研发当中，设计的规范应尽量满足单一责任原则。接口一定要做到单一责任原则，类的设计尽量做到只有一个引起变化的原因。
2.里氏替换原则
定义： 所有引用父类的地方，必要能透明的使用其子类
优点：低耦合，高内聚，增强程序的健壮性。版本升级时，只需新增对应的实现子类，不必影响旧的业务逻辑
缺点： 继承是侵入性的，子类必须拥有分类的所有属性和方法，同时可能造成子类代码冗余、灵活性降低
总结： 在项目中，采用里氏替换原则，应尽量避免子类的个性（拥有自己的业务实现方法），把子类当父类使用，个性无法使用，单独作为一个业务，耦合关系复杂
3.依赖倒置原则
定义： 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。
优点： 减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和维护性
缺点： 前期需要耗时进行结构设计及抽象提取
总结： 依赖倒置原则的本质就是通过抽象（接口或抽象类）使各个类或模块的实现彼此独立，不相互影响，实现模块间的松耦合。在实践中可以根据以下几个规则来衡量：
每个类尽量都有接口或抽象类，或者抽象类和两者都具备
任何类尽量都不应该从具体的类派生
结合里氏替换原则
接口隔离原则
定义： 客户端不应该依赖它不需要的接口，类间的依赖关系应该建立在最小的接口上
优点： 接口隔离的原则将非常庞大、臃肿的接口拆分成更小的和更具体的接口，这样客户将会只需要知道他们感兴趣的方法。接口隔离原则的目的是系统解开耦合，从而容易重构、更改和重新部署缺点： 需要耗时统筹接口隔离颗粒度，接口拆分的标准、颗粒度比较难划分，太大降低灵活性，太小，导致接口数据增大，开发成本更高总结： 接口隔离原则是对接口的定义，同时也是对类的定义，接口和类尽量使用原子接口和原子类来组织。在实践中可以根据以下几个规则来衡量：
一个接口只服务于一个子模块或业务逻辑
通过业务逻辑压缩接口中的public方法，尽量让接口精简，而不是暴露一大堆方法
已被污染的接口，尽量去修改，若变更风险较大，则采用设配器模式进行转换处理
根据业务，每个项目或产品都有特定的环境因素，拆分的标准可能不同，不要硬套标准
5.迪米特原则
定义： 一个对象应该对自己需要耦合或调用的类知道最少，尽量不要对外公布太多的public方法和非静态的public变量
优点： 迪米特法则的核心观念就是类间解耦，提高类的复用率
缺点： 可能产生大量的中转或者跳转类，导致系统的复杂性提高
总结： 迪米特法则是要求类间解耦，但解耦是有限度。在实际的项目中，要适度的参考运用，严格执行就是“过犹不及”
6.开放封闭原则
定义：软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是，对于修改是封闭的。
优点：
避免修改代码，影响已经通过单元测试等原业务逻辑
可以提高复用性、可维护性
缺点： 需要预知变化，全局统筹。
总结： 在将开闭原则运行到实际的项目中需注意:
抽象约束，通过接口或者抽象类约束扩展，对扩展进行边界开放。
元数据控制模块行为，通过配置参数（文件，数据库），减少重复开发
制定项目章程
封装变化，第一将相同的变化封装到同一个接口或者抽象类中；第二将不同的变化封装到不同的接口或抽象类中，不应该有两个不同的变化出现在同一个接口或抽象类中。
