设计模式（二）----四大原则
原则一：单一职责原则（SRP），就一个类而言，应该引用一个引起它变换的原因。具体就是尽量简化类的方法。通俗的说，即一个类只负责一项职责。
具体可见：http://blog.csdn.net/zhengzhb/article/details/7278174这的讲解非常详细。
原则二：开放-封闭原则，是说软件实体（类/模块/函数等等），应该可以扩展，但是不可修改。
对于程序设计而言，怎么的设计才能面对需求的改变却可以保持相对的稳定，从而可以使得系统可以再第一个版本的基础上不断的推出新版本呢？
答案是应用该原则。
既然，需求不可能不变，并且设计也不可能考虑那么全面。但是我们要尽量保证类设计的很好，当新功能来了，只需要增加类，而不是要修改类。但是并不能预先知道哪些功能是可以被隔离的，但是我们尽量做到封闭-开放。
如果在最开始的时候，设计的类，需要发生变化，增加一个功能，则在这里需要考虑重构原来的代码，隔离也就是创建抽象。
比如，设计了一个加法算法，当来了一个需求是要减法时，我们就考虑设计一个继承了。
开放封闭原则是面向对象的核心所在，遵循这个原则可以带来面向对象所谓的巨大好处，也就是可维护，可扩展，可复用，灵活性好。然而，对于应用程序中的每个部分都刻意的抽象同样不是一个i好主意，拒绝不成熟的抽象和抽象一样重要。
原则三：依赖到转原则
问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。
解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。
原则四：迪米特法则
问题由来：类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
解决方案：尽量降低类与类之间的耦合。
自从我们接触编程开始，就知道了软件编程的总的原则：低耦合，高内聚。无论是面向过程编程还是面向对象编程，只有使各个模块之间的耦合尽量的低，才能提高代码的复用率。低耦合的优点不言而喻，但是怎么样编程才能做到低耦合呢？那正是迪米特法则要去完成的。
迪米特法则又叫最少知道原则，最早是在1987年由美国Northeastern University的Ian Holland提出。通俗的来讲，就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。迪米特法则还有一个更简单的定义：只与直接的朋友通信。首先来解释一下什么是直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖、关联、组合、聚合等。其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。也就是说，陌生的类最好不要作为局部变量的形式出现在类的内部。
来自： http://blog.csdn.net/zhengzhb/article/details/7296930