您的位置:首页 > 其它

读「SOLID」的设计原则记录

2019-11-18 18:06 1511 查看

阅读链接:https://xueyuanjun.com/post/9719

单一职责原则Single Responsibility Principle)

        一个类只做某一件事。

        例:操作订单时我们需要查询数据进行验证 如果在订单类中直接查询MySql数据库就意味着 数据存储方式发生改变这里也需要改代码 这时我们可以另起一个订单资料类进行调用保存数据 这样我们的代码就 更清晰、更容易维护、更加解耦、更容易测试

 

开放封闭原则Open Closed Principle)

        对扩展是开放的,对修改是封闭的。

        例:我们需要验证订单,订单验证又随着业务规则改变,随着业务的增长就需要增加一大推新规则,代码必须随着每次业务规则的改变而改变 这样是对修改开放的就违反了开放封闭原则。我们可以:定义订单验证接口 --> 封装订单处理器 --> 每一个订单验证接口的实例注入到订单处理器中 --> 订单操作时调用订单处理器

 

里氏替换原则Liskov Substitution Principle)

        对象可以被其子类的实例所替换,并且不会影响到程序的正确性。

        例:原来的订单数据存储到了 CSV 格式的文件系统中(CsvOrderRepository ),现在需要更换存储方式,存到关系数据库中(DatabaseOrderRepository )。原来的CSV文件系统不需要账户密码而关系数据库需要,如果在OrderProcessor处验证是否调用了关系型数据并传账号密码,就违反了里氏替换原则。DatabaseOrderRepository需要自己接管数据库账号密码以及连接,这样我们就可以在 CsvOrderRepository 和 DatabaseOrderRepository 实现之间进行切换了,不用对 OrderProcessor 做任何修改

如果不遵守里氏替换原则,那么可能会影响到我们之前已经讨论过的其他原则。不遵守里氏替换原则,那么开放封闭原则一定也会被打破。因为,如果调用者必须检查实例属于哪个子类,则一旦有了新的子类,调用者就得做出改变。

 

接口隔离原则Interface Segregation Principle)

        不应该强制接口的实现依赖于它不使用的方法。在实际操作中,这个原则要求接口必须粒度很细,且专注于一个领域。调用方只需要依赖它就可以了,而不必去依赖包含多个领域的接口。

 

依赖反转原则Dependency Inversion Principle)

        高层次的代码不应该依赖低层级的代码,高层次的代码应该依赖抽象接口。低层次代码用于实现一些底层的基本操作,比如从磁盘读文件、操作数据库等。高层次代码用于封装复杂的业务逻辑并且依靠低层次代码来实现功能,但不能直接和低层次代码耦合在一起。

       反转的思想:使用这一原则会反转很多开发者设计应用的方式。不再将高层次代码直接和低层次代码以「自上而下」的方式耦合在一起,这个原则规定不论高层级还是低层次代码都要依赖于一个高层次的抽象,从而使得低层次代码依赖于高层次代码的需求抽象。

 

 

所有五个「SOLID」原则都是相关的,也就是说违背了其中一个原则,通常意味着也违背了其他的原则。当你违背了接口隔离原则,肯定也违背了单一职责原则。

 

 

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签:  Solid