一谈到设计模式，相信每一个程序员都会用到，有时候即使你没有刻意的去使用，但是在构建代码时也都无形之中用到了它们。因为它们是正确的，是代码界的真理。今天在网上搜了搜设计模式，无意之中看到了一篇关于设计模式六大原则的文章，写的很不错，开一帖总结整理一下。
原文作者连接：设计模式六大原则
本文略去一些举例，但就以作者个人的见解进行总结，如果之前没有了解过设计模式六大原则的人，建议去看原文。好了，下面进入正题。
一 单一职责原则
单一职责原则就是要求我们一个类或一个最小模块只干一件事，将任务功能最小化。随着需求的扩充，我们有时候会习惯性地拓展原有类，久而久之，类会变得庞大起来，最终修改维护起来变得非常困难。
二 里氏替换原则
当我们进行类的继承时，子类可以增加方法，而不应该修改父类的方法。有时候子类会用到父类的具体方法，但是如果不慎重写修改了父类的方法，会导致程序运行结果与我们期待的有偏差。在继承时，我们应该注意尽量不修改父类已经实现的方法，可以通过增加新方法来实现新需求。
三 依赖倒置原则
依赖倒置原则告诉我们高级模块不该依赖低级模块，而且应该通过接口建立彼此之间的依赖关系。有时候高级模块会用到很多低级模块的方法，如果直接建立依赖关系，则会增加高级模块调用低级模块方法数量的成本。如果建立高级模块调用接口的方法，每个低级模块的方法实现该接口，则可以实现一次调用，可以应对多种低级模块的方法调用。
四 接口隔离原则
接口的设计应当保持一个适当的大小，减少依赖建立时，不得不实现没有用到的方法。在我们设计实现接口时，有时候会因需求的增加而不断扩充接口内的方法，当依赖关系复杂时，会出现多个模块依赖同一接口，但是却不需要实现接口内的全部方法，这样就造成了浪费。我们应该将接口的设计维持在一个合理的大小，既保证依赖的使用不会实现无用方法，又不会变成接口过多导致大量的实现。
五 迪米特法则
一个类应该保持对其他对象最少的了解。在类与类之间有耦合关系时，我们应该尽量减少耦合，如需用到其他类的成员变量或方法时，尽量有其他类直接提供，而不应该维持控制在调用类中。复杂的逻辑应当封装在类内部，对外只提供公共方法调用结果。
六 开闭原则
一个软件实体如类，模块和函数应当对扩展开放，对修改关闭。开闭原则是六大原则的终极体现，将前五个原则做到了，开闭原则自然就得到了实现。核心思想是当我们开发一个新功能和需求时，不应该影响到原有的功能逻辑，导致新功能的开发对旧功能的结果有影响。
总的来说，在程序设计时，我们应该将程序功能最小化，每个类只干一件事。若有类似功能基础之上添加新功能，则要合理使用继承。对于多方法的调用，要会运用接口，同时合理设置接口功能与数量。最后类与类之间要做到低耦合高内聚。