写点什么

OOD 原则

用户头像
X﹏X
关注
发布于: 2020 年 06 月 17 日

简述

本文内容简略,仅适合引导思考和粗浅的理解,具体实例需查阅相关资料。

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

https://docs.microsoft.com/en-us/archive/blogs/cdndevs/the-solid-principles-explained-with-motivational-posters


开闭原则

  • 对扩展开发(open for extension)

  • 对更改封闭(close for modification)



痛点: 对原代码修改,可能引入错误,并且需要重新测试。

方案: 尽量通过扩展软件来实现,减少对原软件的修改(类,模块函数)。


依赖倒置原则

  • 高层依赖抽象,高层不依赖实现

  • 实现依赖抽象,抽象不依赖实现



痛点: 面向过程的开发,上层调用下层,上层依赖于下层,当下层剧烈变动时上层也要跟着变动,这就会导致模块的复用性降低而且大大提高了开发的成本。

方案: 依赖抽象,减低耦合度。



好莱坞规则: Don't call me, I'll call you.

个人理解 : 高层只需注入信息,等待底层调用。




里氏替换原则

  • 父类调用的地方可用子类替换

  • 父类的改动不影响子类行为



痛点: 继承带来的侵入性,增加了耦合性,降低了代码灵活性

约束:

  • 子类必须实现父类的抽象方法,但不得重写(覆盖)父类的非抽象(已实现)方法。

  • 子类中可以增加自己特有的方法。

  • 当子类覆盖或实现父类的方法时,方法的前置条件要比父类方法的输入参数(形参)更宽松。

  • 当子类的方法实现父类的抽象方法时,方法的后置条件(即方法的返回值)要比父类更严格。


单一职责原则

  • 职责单一,耦合度低

  • 功能细化,内聚性强



痛点: 运行上下文相同,职责1和职责2无关联,但当职责1变更时,可能影响职责2运行。

方案: 隔离无关的上下文环境,将不同的职责封装到不同的类或模块中。


接口分离原则

  • 接口行为明确

  • 无多余依赖接口



方案:

  • 委托进行分离

  • 多继承进行分离




发布于: 2020 年 06 月 17 日阅读数: 56
用户头像

X﹏X

关注

还未添加个人签名 2018.04.25 加入

还未添加个人简介

评论

发布
暂无评论
OOD原则