讲讲solid原则

           

前言

在程序设计领域， SOLID（单一功能、开闭原则、里氏替换、接口隔离以及依赖反转）是由罗伯特·C·马丁在21世纪早期引入，指代了面向对象编程和面向对象设计的五个基本原则。当这些原则被一起应用时，它们使得一个程序员开发一个容易进行软件维护和扩展的系统变得更加可能。

单一职责原则

一个类只负责一件事，也就是把关联性强的内容聚合到一个类里面，不掺杂其它的影响。

开放封闭原则

实体应该对扩展是开放的，对修改是封闭的。即可扩展(extension)，不可修改(modification)。

例子：开发中很多场景下会采用消息中间件解耦，如何对消息处理统一管理呢？可能刚开始考虑不全会导致后续开发无奈地采用if-else来打补丁似的完成需求，但这种情况下经常reopen已稳定运行在线上的代码，不可避免会有机率因为更改造成线上故障。那么如何秉持开放封闭原则来统一处理呢？

可考虑设计将变化放在处理器上，而管理这些处理器的注册器不可修改，如果有新的业务需求只需增加处理器处理即可。

消息注册器

消息处理器

里式替换原则

一个对象在其出现的任何地方，都可以用子类实例做替换，并且不会导致程序的错误。

经典的例子: 正方形不是长方形的子类。原因是正方形多了一个属性“长 == 宽”。这时，对正方形类设置不同的长和宽，计算面积的结果是最后设置那项的平方，而不是长*宽，从而发生了与长方形不一致的行为。如果程序依赖了长方形的面积计算方式，并使用正方形替换了长方形，实际表现与预期不符。

接口分离原则

一个类不应该强制让它继承它不需要的接口，可以将接口拆分更细粒度，有助于解耦。

         

          

里式替换原则

一个对象在其出现的任何地方，都可以用子类实例做替换，并且不会导致程序的错误。

经典的例子: 正方形不是长方形的子类。原因是正方形多了一个属性“长 == 宽”。这时，对正方形类设置不同的长和宽，计算面积的结果是最后设置那项的平方，而不是长*宽，从而发生了与长方形不一致的行为。如果程序依赖了长方形的面积计算方式，并使用正方形替换了长方形，实际表现与预期不符。

接口分离原则

一个类不应该强制让它继承它不需要的接口，可以将接口拆分更细粒度，有助于解耦。

接口是设计时对外部设定的“契约”，通过分散定义多个接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。在程序设计中，接口应该专注于对某个模块提供定制服务，屏蔽不需要的服务，接口的范围应该适当，避免过度的隔离会导致项目过于复杂，松散。

依赖倒置原则

高层模块不应该依赖于低层模块，抽象不应该依赖于具体实现。

在微服务开发中，调用其它服务提供方的服务可以快速的完成业务需求。但是存在服务方因业务需求变动过大、优化业务模型等种种原因需要重新发布一版新服务，旧的服务可能会存在下线风险，而我们业务依赖于服务方的服务，如何让我们尽可能地少改动代码？在设计中，可以想到在外部模块ext直接设计一个符合业务的接口，接口实现调用服务方远程服务，利用Convert转换，数据对象直接拷贝过来，保障稳定性。这符合DIP原则，可能在引入新依赖方的时候有点麻烦，但是这样可以很方便后续的替换服务，最大程度降低后续维护成本。

后续

点个关注，顺便加点料来一篇你写的代码，是别人的噩梦吗？看看会不会心绪来潮？

喜欢的读者可以关注路上小栈，及时获取最新的技术文章，专注源码分析、技术业务思考等。