面向对象的四大设计原则

最关键的软件开发工具是受过良好设计原则训练的思维

开放-封闭原则（the Open-Close Principle . OCP)

• 开放：模块的行为必须是开放的，是可扩展的(面向扩展；开放）
• 封闭：对系统进行扩展是不影响其他部分的代码（面向修改：关闭）
• 问题由来：在软件开发的生命周期内，因为变化，升级或维护等原因需要对代码原有的进行修改时，我们可能会给旧的代码引入错误，也可能令我们不得不对整个功能进行重构，并且需要对原有代码经过重新测试，
• 解决方案：当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改现有的代码来实现变化

“单一职责”原则（SRP：Single responsibility principle）

• 一个具体的设计元素（类或接口），只能完成某一类专门 的功能（职责）

• 问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变时，而需要去修改类T时，有可能会导致原本运行正常的职责P2功能发生故障

• 解决方案：遵循单一职责原则，分别建立两个类T1和T2，使T1完成职责P1功能是，T2完成职责P2的功能。这样，当修改类T1时，不会使职责P2发生故障风险，同理，当修改T2时，也不会 使职责P1发生故障。

“接口隔离”原则（Interface Segregation Principle ISP）

• 一个类对另一类的依赖应当建立在接口上。
• 使用多个专门的接口比使用单一复合接口要优越、
• 问题由来：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小的接口，则类D和类B必须去实现他们不需要的方法。
• 解决方案：将臃肿的接口I拆分成独立的几个接口，类A和类C分别于他们需要的接口建立依赖关系。也就是采用接口隔离原则。

“依赖倒置”原则

• 上层不应该直接依赖于下层，上、下应该共同依赖于抽象（接口）----即上层调用接口，下层实现接口
• 抽象不能依赖于具体，具体依赖于抽象。系统的核心逻辑不能依赖于具体的实现细节
• 问题由来；类A直接依赖于类B，假如要将A改为依赖于类C，则必须通过修改类A的代码来实现，这种场景下，类A一般是最高层模块，负责复杂的业务逻辑，类B和类C是底层模块，负责基本的源自操作，假如修改类A，会给程序带来不必要的风险
• 解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，A通过接口I间接与类B或类C发生联系，则会大大降低修改类A的几率。