讲讲solid原则

           

前言程序员

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

单一职责原则微服务

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

开放封闭原则优化

实体应该对扩展是开放的,对修改是封闭的。便可扩展(extension),不可修改(modification)。设计

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

可考虑设计将变化放在处理器上,而管理这些处理器的注册器不可修改,若是有新的业务需求只需增长处理器处理便可。
orm

消息注册器cdn


消息处理器
中间件


里式替换原则

一个对象在其出现的任何地方,均可以用子类实例作替换,而且不会致使程序的错误。

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

接口分离原则

一个类不该该强制让它继承它不须要的接口,能够将接口拆分更细粒度,有助于解耦。

         

          

里式替换原则

一个对象在其出现的任何地方,均可以用子类实例作替换,而且不会致使程序的错误。

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

接口分离原则

一个类不该该强制让它继承它不须要的接口,能够将接口拆分更细粒度,有助于解耦。

接口是设计时对外部设定的“契约”,经过分散定义多个接口,能够预防外来变动的扩散,提升系统的灵活性和可维护性。在程序设计中,接口应该专一于对某个模块提供定制服务,屏蔽不须要的服务,接口的范围应该适当,避免过分的隔离会致使项目过于复杂,松散。

依赖倒置原则

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

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

后续

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

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

相关文章
相关标签/搜索