简述

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

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运行。

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

接口分离原则

• 接口行为明确

• 无多余依赖接口



方案:

• 委托进行分离

• 多继承进行分离