笔者工作一年半，积累了一定工作阅历，于今日对SOLID设计原则有了更近一步的领悟，特作此文以记之。
- 内容预览：
- 1. 单一职责(Single Responsibility Principle)
- 2. 开闭(Open Closed Principle)
- 3. 李氏替换(Liskov Substitution Principle)
- 4. 接口隔离(Interface Segregation Principle)
- 5. 依赖倒置(Dependence Inversion Principle)
内容预览：
1. 单一职责(Single Responsibility Principle)
1.1 关键理解
一个类只做一件事，简化类内容
1.2 场景举例
一个需求里包含下载文件与上传文件的内容，宜分别实现一个专门上传/下载的类，不要为了快速完成单次任务而将代码都耦合到一处，使得代码复用性很差。
微服务调用，facade层的DTO宜与service层的DTO区分开，主要是service层也宜单独设置一套DTO，不直接依赖使用facade层的内容，相互独立。这样service模块的改动不影响facade模块的依赖方。例如，service里的DTO需要设置一些序列化的注解（XML、Json等），而这些注解是facade的依赖方不需要关注的。
正方形绘图方法与面积计算方法宜拆开，面积计算方法属于几何正方形，正方形继承几何正方形实现绘图方法。这样，仅需要计算面积的调用方就不用引入GUI的依赖包了。
2. 开闭(Open Closed Principle)
2.1 关键
为需求变更预留空间，开发的时候尽量多支持不同场景
2.2 场景举例
开发一个拉取账单文件的定时任务，虽然需求很明确是SFTP的方式拉取，但开发的时候也应该给FTP留出空间。这样当需求有变时，能不改代码就支持
3. 李氏替换(Liskov Substitution Principle)
3.1 关键
子类应是父类的拓展，不能出现子类做不到父类的事情的情况
3.2 场景举例
人骑马，白马和黑马都马，但不能骑的马例如小马则不应该继承马。小马继承了马，但小马又不能被骑，就有的为了继承而继承，不合理。继承父类至少应该实现父类的全部功能。
4. 接口隔离(Interface Segregation Principle)
4.1 关键
接口设计一定要准确细致，不要让接口继承非必要的方法，减少被误用的风险。
4.2 场景举例
连接类 与 连接管理类 区分开，连接对象不宜包含 连接管理类 的方法，例如建立连接。如果连接类里也包含建立连接的方法，则可能会因方法误用而影响到共享的资源(共享的连接)。
5. 依赖倒置(Dependence Inversion Principle)
5.1 关键
模块依赖之间宜加设中转模块，完成解耦
5.2 场景举例
与SpringIOC设计原理同。导演需要有人演角色，不必关系由哪个人来演。公司岗位一个萝卜一个坑，公司只关注需要开设哪些坑，填坑的人是跟公司没有强依赖关系的。