设计模式：单一职责原则、开放-封闭原则以及依赖倒置原则

在设计代码中，我们有许多可以依照的设计模式，让我把整个项目的逻辑结构变得清晰易于维护。当然，在设计模式中我们不只有各种模式，还有许多设计的原则，虽然他们不是代码架构的模板，但是这些原则却时刻提醒我们提高代码质量和防止未来麻烦。这次我就将单一职责原则、开放-封闭原则以及依赖倒转原则进行解释。

一、单一职责原则

专业解释：单一职责原则（SRP），就一个类而言，应该仅有一个引起它变化的原因。如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭到意想不到的破坏。

其实很好理解，举个例子，就像需要写一个能够适用于Windows的可视化界面程序，很多人会将业务逻辑代码和界面代码混写在一起，这样做确实可以将任务完成，但是这样子会出现一个问题，当我需要一个同样的能够在IOS上运行的可视化界面程序，这个时候我就需要对整个程序进行重构。如果在最开始我就讲业务逻辑代码和界面代码进行分离，那么当界面代码需要变化的时候，就对业务逻辑代码影响不大，从而起到了复用的效果。

当然，这样说起来比做起来容易，软件设计真正要做的有许多内容，就是发现职责并把那些职责分离，其实去判断是否分离也不难，那就是如果你能找到多于一个动机去改变这个类，那么这个类就有多于一个职责。

二、开放-封闭原则

专业解释：开放-封闭原则，是说软件实体（类、模块、函数等等），应该可以扩展，但是不可以修改。对于扩展是是开放的，对于修改是封闭的。

开放-封闭原则给我们的启发是，如何设计才能面对需求的改变却可以保持相对稳定，从而可以使系统才在第一个版本以后不断推出新的版本。这个原则其实和单一职责原则有一定相似的地方，都是将程序尽可能的模块化，降低耦合度，但是开发-封闭原则还强调为以后的扩展做准备。就像我们在之前提到过的例子，写一个计算器程序，最开始的需求只有加减乘除，但以后可能会增加如根号等需求，基于这一点，我们就需要考虑到开放-封闭原则，使用一些方式达到在需求变动的时候，降低我们的工作量，从而我们想到了使用简单工厂模式。

绝对的对修改关闭是不可能的，无论模块是多么“封闭”，都会存在一些无法对之封闭的变化，既然不可能完全封闭，设计人员就应该对他设计的模块应该对哪种变化封闭做出选择，他必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离那些变化。

当然我们不可能在设计程序之初就预测好所有的变化，所以我们在最初编写代码时，假设变化不会发生，当变化发生时，我们就构造抽象来隔离以后发生的同类变化。

开放-封闭原则是面向对象设计的核心所在，遵循这个原则可以带来面向对象技术所声称的巨大的好处，也就是可维护、可扩展、可复用、灵活性好，开发人员就应该对程序中出现频繁变化的那部分做出抽象，然而，对于应用程序中每一个部分刻意的进行抽象并不是一个好主意，拒绝不成熟的抽象和抽象本身一样重要。

三、依赖倒置原则

专业解释：高层模块不应该依赖底层模块，两个都应该依赖抽象。抽象不应该依赖于细节，细节应该依赖抽象。依赖倒置可以说是面向对象设计的标志，用那种语言来编写程序不重要，如果编写时考虑的都是如何针对抽象程序编程而不是针对细节编程，即程序中所有依赖关系狗屎终止于抽象类或接口，那就是面向对象设计，反之就是过程化设计。

以修电脑为例，更换CPU、内存卡等，其实其中就有好几种面向对象的几个设计原则。如我们之前讲到的单一职责原则，电脑的内存坏了，不应该成为更换CPU的理由，他们之间各自的职责很明确，再比如封闭-开放原则，内存不够只要插槽足够就可以添加，硬盘不够可以用移动硬盘，PC的接口是有限的，但只要软件系统设计的好，却可以无限的扩展。而在依赖倒置原则中，抽象不应该依赖细节，细节应该依赖于抽象，说白了就是针对接口编程，要对实现编程，无论主板、CPU、硬盘都是针对接口设计的，如果针对现实来设计，那么在设计主板CPU等时，就需要知道不同牌子的不同接口。