从事开发这么多年，陆陆续续开发了N个系统了。对软件设计原则，一直没有认真深入的探讨过，当熟读这些原则，结合项目，发现很多违背设计的地方，作为优秀的研发，应该早点跟三字经一样熟读这些原则才对啊。下面我结合最近的项目谈谈自己的见解。

开闭原则

官方解释 对扩展是开放的，对修改是关闭的。
简单地说，就是你要提供这样的函数方法或者类，你可以进行重载，复写，但是不需要修改。例如，刚开始，火车票电子票出票流程，我在controller层调用business层提供的出票方法。设计的时候，预测到后期还有其他票种，我抽象出一个IOccupyBusiness接口，里面就一个请求占位方法，实现该接口新建实现类EticketOccupyBusiness，在occupy（）写电子票的业务。
过了不久，产品提了一个配送票的出票需求，我只需要添加一个实现IOccupyBusiness的实现类DeliveryOccupyBusiness，在occupy（）写配送票的业务，我并没有修改已有类，和方法，复合了开闭原则。

接口隔离原则

客户端不应该依赖它不需要的接口；
一个类对另一个类的依赖应该建立在最小的接口上。
简单说，不要给调用方暴露它不需要调用的方法。
还拿上述的例子，如果遵循单一职责原则，请求占位，与占位反馈，可以设计成同个接口的不同方法。如果需求是这样的，配送票的占位是虚占，不需要耗时的请求12306实占，所以可以占位接口设计成同步反馈结果，则没有异步反馈的方法。那么配送票的实现类就多暴露出一个占位反馈的方法，不符合接口隔离原则，于是我又将占位接口，粒度细化了，分占位请求接口，占位反馈接口。这样，占位的实现类就不会实现多余的接口了。

单一职责原则

官方定义：有且仅有一个让类变化的原因。
通俗地说，就是一个类只负责一个职责，比如上面我们谈到的，占位的类，不能同时有出票的功能。
单一职责与接口隔离原则有点类似，单一职责偏向于职能，接口隔离偏向于接口粒度。

里氏替换原则

官方定义：所以引用基类的地方必须透明的使用子类对象
通俗地说，就是子类可以扩展父类的功能，但不能改变父类的功能，即不能重载、复写父类的方法

迪米特法则

官方定义：一个对象应该对其他对象保持最少的了解

依赖倒置原则

官方定义 译文：
高层模块不应该依赖于低层模块，它们应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。

基于以上学习，我在项目里面实现了这样类图