四:单一职能原则

　　定义:一个类而言，应该仅有一个引起他变化的原因[DH]

　　也是说，不要把变化原因各不相同的职责放在一起，因为不同的变化会影响到不相干的职责。再通俗一点地说是，不该你管的事情你不要管，管好自己的事情可以了，多管闲事害了自己也害了别人。(当然这里说的多管闲事跟见义勇为是两回事，我们提倡见义勇为！)
这个是说，一个类尽量做到了功能单一，比如在mvc中，判断数据的类和添加数据库的类一定要分开。单一职能的不是说职能多了我们实现不了，是为了后期的测试维护，每个类的很单一，我们找错误的时候可以一步到位。添加新的功能的时候，也不用牵扯到很多的类。

　　在设计模式中的体现:

　　烤肉者管烤肉，他也不管收钱，也不管记录。这样把"地摊"上的烤肉者分成服务员和烤肉的人。让职责单一。不容易出错。

　　上边的都是几个原则，下面介绍两个法则:

　　(1)迪米特法则:系统中的类，尽量不要与其他类互相作用，减少类之间的耦合度，因为在你的系统中，扩展的时候，你可能需要修改这些类，而类与类之间的关系，决定了修改的复杂度，相互作用越多，则修改难度越大，反之，如果相互作用的越小，则修改起来的难度越小。。例如A类依赖B类，则B类依赖C类，当你在修改A类的时候，你要考虑B类是否会受到影响，而B类的影响是否又会影响到C类。。如果此时C类再依赖D类的话，呵呵，我想这样的修改有的受了。。


　　(2)接口隔离法则:这个法则与迪米特法则是相通的，迪米特法则是目的，而接口隔离法则是对迪米特法则的规范。。为了做到尽可能小的耦合性，我们需要使用接口来规范类，用接口来约束类。要达到迪米特法则的要求，好是实现接口隔离法则，实现接口隔离法则，你也满足了迪米特法则。。。

　　这里也体现了一个依赖原则，要尽量依赖抽象，不要依赖具体。

　　设计模式中的体现:高层模块依靠接口和底层模块依赖。

　　总结:学习设计模式的基础是理解设计原则，只用理解了这些原则，加上OO的三大特性。再去体会设计模式满足那些原则。后达到你可以运用这些原则来写出自己的设计模式来，这才是高境界。我在看了一遍大话设计模式以后，将其中的思想总结出来。和大家分享。