设计模式的六大原则

        一、单一职责原则

　　Single Responsibility Principle，接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。

　　二、里氏替换原则

　　Liskov Substitution Principle，通俗点讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必就能适应。

　　三、依赖倒置原则

　　Dependence Inversion Principle，高层模块不应该依赖低层模块，两者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象;在Java语言中的表达就是，模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的;接口或抽象类不依赖于实现类;实现类依赖接口或抽象类。

　　四、接口隔离原则

　　Interface Segregation Principle，这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。还是一个降低类之间的耦合度的意思，从这儿我们看出，其实设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。所以上文中多次出现：降低依赖，降低耦合。

　　五、迪米特原则

　　Law of Demeter，一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，你(被耦合或调用的类)的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的这么多public方法，我就调用这么多，其他的我一概不关心。

　　六、开闭原则

　　Open Closed Principle，软件实体应该对扩展开放，对修改关闭，其含义是说一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。

　　总结：

　　之所以有这么多的原则来指导我们进行程序的设计和开发，是因为我们的程序存在未知的改变。为了以最低的代价拥抱这种未知的变化，前辈们给我们总结了这么多原则，开闭原则应该是每一个大师的终极目标。在所有这些原则中，很重要的一环就是抽象类和接口的灵活运用。后面的23种具体的设计模式也是对“变化“的总结。