设计模式六大原则

软件设计最大的难题就是应对需求的变化，往往我们对这些变化不知所措。我们会遇到系统修改难或者扩展难、代码过分复杂而且重复代码多、公共代码不能复用、系统不够稳定，改完经常出错等一系列问题。如何实现系统的可扩展、可复用、灵活性好、维护性好等就需要好的设计模式了。今天首先介绍设计模式需要遵循的六大原则。

第一：单一职责原则（SPR）

先来看一个场景，一个类中包含两个职责T1和T2，当由于职责T1的需求需要修改类时，很有可能会影响正在执行的职责T2。因此得出单一职责的概念，即一个类应该有且仅有一个原因导致该类的变更，换句话说就时一个类应该只负责一项职责，这个类的变更智能是由这一项职责引起的。

单一职责告诉我们，一个类不能太“累”！当一个类（包括模块和方法）承担的责任越多时，它被复用的可能性越小；而且一个类承担的职责过多就相当于把这些职责都耦合在一起了，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力，因此这种耦合是非常不利的。我们需要做的就是把职责分离，把不同的职责封装到不同的类中。

举个例子来说：

/*
 * 这个接口很明显的有两个职责，即连接管理和数据传送
 */
public interface Modem {
public void dial(String pno);
public void hangup();
public void send(char c);
public void recv();
}

当连接管理或者数据传送发生变化时都会引起这个类发生变化，因此上述接口就违背了单一职责原则，应该把接口拆分如下：

/*
 * 负责连接管理的接口
 */
public interface Connenction {
public void dial(String pno);
public void hangup();
}

/*
 * 负责数据传送的接口
 */
public interface DataChannel {
public void send(char c);
public void recv();
}

现在来总结一下，SRP的优点是消除耦合，减小因需求的变化引起代码僵化的问题。SRP强调的就是根据职责来衡量接口或者类，但是往往我们对于职责的定义时不明确的，因此我们要因项目而异。一个合理的类中尽量做到仅由一个原因引起它的变化；但