"地瓜哥"博客网

不是引子的引子

话说三国时期，曹操带领百万大军攻打东吴，大军在长江赤壁驻扎，军船连成一片，眼看就要灭掉东吴，统一天下，曹操大悦，于是大宴文武百官，在酒席间，曹操诗性大发，不觉吟道：“喝酒唱歌，人生真爽。……”。众文武奇呼：“丞相好诗！”于是一臣子速命印刷工匠刻版印刷，以便流传天下。

样张出来，给曹操一看，曹操感觉不妥，说道：“喝与唱，此话过俗，应改为‘对酒当歌’较好！”，于是此臣就命工匠重新来过。工匠眼看连夜刻版之工，彻底白费，心中叫苦不迭。只得照办。

样张再次出来，请曹操过目，曹操细细一品，觉得还是不好，说：“人生真爽太过直接，应改问语才够意境，因此应改为‘对酒当歌，人生几何？……’”当臣转告工匠之时，工匠晕倒……

问题出现在哪里？把刻字和软件开发比较，如何才能达到软件工程所讲的可维护、可复用、可扩展以及灵活性好？

授业解惑

引子中所讲的问题其主要原因是三国时期，活字印刷还没发明，所以要改字的时候就必须要整个刻版全部重新刻。如果有了活字印刷，则只需要改四个字就可，其余工作都未白做。

对比刻字和编程，其实二者在工程学的角度来讲是相通的：

1. 要改，只需更改要改之字，此为 可维护；
2. 这些字并非用完这次就无用，完全可以在后来的印刷中重复使用，此乃 可复用；
3. 如要加字，只需另刻字加入即可，这是 可扩展；
4. 字的排列其实可能是竖排可能是横排，此时只需将活字移动就可满足排列需要，此是 灵活性好。

从八十年代开始，面向对象的分析设计编程思想之所以能越来越流行，正是因为通过封装、继承、多态可以把程序的耦合度降低，再使用设计模式可以使得程序更加地灵活，容易修改，并且易于复用。

这篇文章就是专门来给大家讲解一下在进行面向对象的分析设计时，应该遵循的设计原则，也是设计模式所遵循的原则。扯蛋完毕，转入正题。

单一职责原则

单一职责原则（SRP） ，就一个类而言，应该仅有一个引起它变化的原因。

如果一个类承担的职责太多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合性会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。

软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。 其实要去判断是否应该分离出来，也不难，那就是如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责。

开发中，Web页面的展示与业务逻辑的分离。生活中，这个原则也通用。比如，现在人类没有出现一个全才；再比如，功能越来越强大的手机，再强大，也没有单反相机的照相功能强大。不过，貌似诺基亚要挑战这个原则，诺基亚最近发布了Lumia 1020， 4100 万像素摄像头、4.5 英寸 AMOLED 触摸屏、2GB RAM 以及 32GB 内存的的 Windows Phone。次奥，比单反相机的像素都高，不知道这是手机？还是相机？难怪有网友评论：又能打电话又能当锤子使，这么好的相机哪找去，诺基亚，专注相机一百年。

开放-封闭原则

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

开放-封闭原则有俩个特征：

1. 对于扩展是开放的（Open for extension）；
2. 对于更改是封闭的（Closed for modification）。

在开发任何系统的时候，都不能指望系统一开始时需求确定，就再也不会变化，这是不现实也不科学的想法，而既然需求是一定会变化的，那么如何在面对需求的变化时，设计的软件可以相对容易修改，不至于说，新需求一来，就要把整个程序推到重来。 怎样的设计才能面对需求的改变却可以保持相对稳定，从而使得系统可以在第一版本以后不断推出新的版本呢？开放-封闭原则给了我们答案。

开放-封闭原则的意思就是说，你设计的时候，时刻要考虑，尽量让这个类是足够好，写好了就不要去修改了，如果新需求来，我们增加一些类就完事了，原来的代码能不动就不动。

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

变化很难猜测。但是却可以在发生小变化时，就及早去想办法应对发生更大变化的可能。也就是说，等到变化时立即采取行动。

在最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化。 面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。这正是“开放-封闭原则”的精神所在。

需要说明一下，并不是什么时候应对变化都是容易的。 查明可能发生的变化所等待的时间越长，要创建正确的抽象就越困难。 所以，我们希望的是在开发工作开展不久就知道可能发生的变化。

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

扯蛋时间：生活中，也有一个很好的例子来说明开放-封闭原则：一国两制，一个中国这个原则不能改变，对修改封闭；但是在一个中国的框架下，可以多个出现多个特区，现在有香港特区和澳门特区，也许未来还会有台湾特区，这就是对扩展开放。这样说，应该浅显易懂了。

屌丝一枚，勿谈国事！勿谈国事！

依赖倒转原则

依赖倒转原则 有两中定义方式：

高层模块不应该依赖底层模块。两个都应该依赖抽象；

抽象不应该依赖细节。细节应该依赖抽象。

我们平时常说的“针对接口编程，不要针对实现编程”就是依赖倒转原则的最好体现：接口（这里的接口可以是方法，可以是类，也可以是抽象类，还可以是Java中的interface）就是一种抽象，只要不修改接口声明，大家可以放心大胆调用，至于接口的内部实现则无需关心，可以随便重构。这里，接口就是抽象，而接口的实现就是细节。

如果不管高层模块还是底层模块，它们都依赖于抽象，具体一点就是接口或者抽象类，只要接口是稳定的，那么任何一个的更改都不用担心其他受到影响，这就使得无论高层模块还是底层模块都可以很容易地被复用。

依赖倒转原则其实可以说是面向对象设计的标志， 用哪种语言来编写程序不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即程序中所有的依赖关系都是终止于抽象类或者接口，那就是面向对象的设计，反之那就是过程化的设计。

再扯扯蛋：来举一个生活中的例子，电脑中内存或者显卡插槽，其实是一种接口，而这就是抽象；只要符合这个接口的要求，无论是用金士顿的内存，还是用三星的内存，无论是4G的，还是8G的，都可以很方便、轻松的插到电脑上使用。而这些内存条就是具体实现，就是细节。

里氏代换原则

里氏代换原则 ，子类型必须能够替换它们的父类型。

一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化。

只有当子类可以替换掉父类，软件单位的功能不受影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。

正是由于子类类型的可替换性才使得使用父类类型的模块在无需修改的情况下就可以扩展。不然还谈什么扩展开放，修改关闭呢？！再回头来看依赖倒置原则，高层模块不应该依赖底层模块，俩个都应该依赖抽象，相信你对这句话有更深入的理解。

扯扯更健康：还是生活中的例子，戏班中唱戏，今天师傅生病了，不能出演，但是戏还是要照常唱，怎么办？这是，可以让徒弟上场，徒弟的本事都是师傅传授的。唱戏的本身就是戏班所需的功能，师傅唱的，只要师傅教过了，徒弟也可以上，这是子承父业。这就是里氏代换！

迪米特法则

迪米特法则 ,也叫最少知识原则。如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某个方法的话，可以通过第三者转发这个调用。

迪米特法则首先强调的前提是在类的结构设计上，每个类都应当尽量降低成员的访问权限，也就是说，一个类包装好自己的private状态，不需要让别的类知道的字段或行为就不要公开。

迪米特法则其根本思想，是强调了类之间的松耦合。 类之间的耦合越弱，又有利于复用，一个处于弱耦合的类被修改，不会对有关系的类造成波及。也就是说，信息的隐藏促进了软件的复用。

不举例真的会死：再来举个生活中的例子，比如入职或者离职时，办人力资源部签合同，如果你明确说找人力资源部的小李手续，但是如果小李恰好不在，也许你就会被撂一边了；但是，如果你说找人力资源部办，那么不管人力资源部谁在，都有责任帮你办理。这里人力资源部就相当于一个类，而人力资源部的小李（当然也包括其他人力资源部的同事）就是类的内部实现。

总结

• 软件工程追求的是软件的可扩展、可维护、可复用以及灵活性好；
• 单一职责原则是面向对象设计的追求；
• 开放-封闭原则是面向对象设计的核心所在；
• 依赖倒转原则其实可以说是面向对象设计的标志；
• 里氏代换原则，是面向对象的根本，正是这个原则，才使得依赖倒转原则成为可能；
• 迪米特法则其根本思想，是强调了类之间的松耦合。

特别感谢

实际上这篇文章可以看做是《大话设计模式》的读书笔记，文章中的大部分内容是从书中摘录过来的。所以，特别感谢书的作者程杰，写出这么通俗易懂的书！