设计模式（Design pattern）是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。
使用设计模式的根本原因是适应变化，提高代码复用率，使软件更具有可维护性和可扩展性。并且，在进行设计的时候，也需要遵循以下几个原则：
单一职责原则 (Single Responsibility Principle，SRP)
一个模块的组成元素之间的功能相关性。从软件变化的角度来看，就一个类而言，应该仅有一个让它变化的原因；通俗地说，即一个类只负责一项职责。
假设某个类 P 负责两个不同的职责，职责 P1 和 职责 P2，那么当职责 P1 需求发生改变而需要修改类 P，有可能会导致原来运行正常的职责 P2 功能发生故障。
开放-关闭原则 (Open-Closed Principle，OCP)
软件实体 (类、模块、函数等等) 应该是可以被扩展的，但是不可被修改。即每次发生变化时，要通过添加新的代码来增强现有类型的行为，而不是修改原有的代码。
如果一个软件能够满足 OCP 原则，那么它将有两项优点：
- 能够扩展已存在的系统，能够提供新的功能满足新的需求，因此该软件有着很强的适应性和灵活性。
- 已存在的模块，特别是那些重要的抽象模块，不需要被修改，那么该软件就有很强的稳定性和持久性。
里氏替换原则 (Liskov Substitution Principle，LSP)
所有父类出现的地方，子类都可以出现，并且将父类对象替换为子类对象的时候，程序不会抛出任何异常或者错误，因此我们需要注意的是，尽量不要重载或者重写父类的方法(抽象方法除外)，因为这样可能会改变父类原有的行为。
里氏替换原则通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。
依赖倒转原则 (Dependence Inversion Principle，DIP)
高层模块不应该依赖低层模块，二者都应该于抽象。进一步说，抽象不应该依赖于细节，细节应该依赖于抽象。也就是提出的 “面向接口编程，而不是面向实现编程”。这样可以降低客户与具体实现的耦合。
接口隔离原则 (Interface Segregation Principle，ISP)
使用多个专门的接口比使用单一的总接口要好。也就是说不要让一个单一的接口承担过多的职责，而应把每个职责分离到多个专门的接口中，进行接口分离。过于臃肿的接口是对接口的一种污染。
但是凡事都要有个度，如果接口设计过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。
迪米特法则（Law Of Demeter，LOD）
迪米特法则（Law of Demeter，LoD）又叫最少知识原则（Least Knowledge Principle，LKP），指的是一个对象应当对其他对象有尽可能少的了解。也就是说，一个模块或对象应尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立，这样当一个模块修改时，影响的模块就会越少，扩展起来更加容易。
组合/聚合复用原则 (Composite/Aggregate Reuse Principle，CRP)
在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分; 新的对象通过向这些对象的委派达到复用已有功能的目的。简单地说，就是要尽量使用合成/聚合，尽量不要使用继承。
在面向对象的设计中，如果直接继承基类，会破坏封装，因为继承将基类的实现细节暴露给子类；如果基类的实现发生了改变，则子类的实现也不得不改变；从基类继承而来的实现是静态的，不可能在运行时发生改变，没有足够的灵活性。于是就提出了组合/聚合复用原则，也就是在实际开发设计中，尽量使用组合/聚合，不要使用类继承。
所有设计原则追求的宗旨还是保证系统的低耦合高内聚，指导它们的原则无非就是封装变化，责任单一，面向接口编程等设计原则。
设计模式系列：