用设计模式来理解炮轰华为读后感

最近看了一篇文章“代码的坏味道”提到，‘我们通常希望软件能够更容易被修改——毕竟软件再怎么说本来就该是“软”的’。我觉得这种提法很有趣，刚好我最近想回顾一下做软件设计的心得，所以就记了下来。当然，并不是所有的文章都值得我去记，就像广告中的“并不是所有的牛奶都叫xxx”……

 

     如何让我们的软件变得易修改？ 我在上篇博文序中提到了框架设计的评价标准，“关闭修改，开放扩展”。这里如果单从字面上看，好像有些矛盾，要让易修改，又要关闭修改；倒挂的人马上就来一句， 既要让马儿跑， 又要让马儿不吃草。 不错，假如有一天你当了老板的时候，可能就能体会BOSS的心态了。那么现在就让我们把软件当成员工，体验的做一回“主人”吧。

 

     这里的体验，只是让你经历一个简单的思想旅程。“关闭修改，开放扩展”怎么理解呢？ XX公司的老板最近在提，主流程要简洁， 末端流程要灵活开放。何谓简洁？ 简洁的东西其实就是能保持稳定的东西，形而上的东西。聚焦主干道，主干道必须要保持稳定通畅。主流程就是原则性的问题，非原则性的问题不能放到主流程上来，以保持主流程的简洁，而一旦放到主流程上来的业务原则就要关闭修改，以保持稳定和原则的可坚持性。末端流程一般都是基于主流程之外的扩展，末端是变化的，往往是不可以预测或可预测的周期范围很短的或者多样性。搞编程的人一看到多样性，就会想到面象对象的三个基本特性之一“多态”了吧，没错，把非主流人业务都可以认为是多态，即多种状态，可变化的状态，简称“变态”。我们把多态看成是设计之基，似乎有点门道了，但还不足以解释什么是“关闭修改，开放扩展”。那么我觉得有五个重点:

 

1、 里氏替换原则，即一个类的的所有对象都可以被另一个类的对象替代，而行为不会发生变化。例如人类的对象，可以被男人替代。也可以被女人替代。

 

2、 迪米特法则， 即类与类之间应该知道的最少。把类看成公司，而不是部门。那么他们的就只能通过规范的商业行为来打交道。

 

3、 依赖倒转。一般情况下，都是高层依赖低层，就像小饭店里，老板指挥员工去干这干那，什么都是口头传达即可，通过威信去影响所有员工的行为。但当做成大饭店以后，老板直接授权是管理不过来了，这时就需要依赖规章制度。依赖倒转的意思就是从直接依赖底层，改为依赖接口，依赖抽象。

 

4、 接口隔离，上面提到了依赖接口和抽象 ，那么当一个接口有过多的功能时，可能并不是高层所需要的，但因为接口已经定义了，不得不去实现一下，这也浪费了时间。就好比，定义了一个人体肠道排泄的接口，一是脱裤子，二是排放。如若放个屁也要实现排泄接口中的脱裤子，那就成歇后语了。当然这个比喻有点不雅。BOSS说谈钱就不高雅了，我这里就现实一点吧，呵呵

 

5、 单一职责。和上边的接口隔离相似，但主要强调的是，一个类不要太臃肿。举个例子就是，不要老说一个人精通英语，又精通汉语。当然我说的是“精通”，不是“精装房”中的简单装修之意。而是和双方的专业人员比，中国说英语最好的人，假如当他的英语达到美国本土国学专业的人的水平之时，那么他的汉语的听说读写能力可能就退化了，至少有些音形词汇是没有那么流利了。这个职责的意思就是让我们把一个东西做精，保持他持续的专业性。

 

好了，简单的介绍了几个原则性问题，如若不能理解，请听下回分解。