赞
踩
软件设计最大的难题就是应对需求的变化,往往我们对这些变化不知所措。我们会遇到系统修改难或者扩展难、代码过分复杂而且重复代码多、公共代码不能复用、系统不够稳定,改完经常出错等一系列问题。如何实现系统的可扩展、可复用、灵活性好、维护性好等就需要好的设计模式了。今天首先介绍设计模式需要遵循的六大原则。
第一:单一职责原则(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强调的就是根据职责来衡量接口或者类,但是往往我们对于职责的定义时不明确的,因此我们要因项目而异。一个合理的类中尽量做到仅由一个原因引起它的变化;但
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。