2.2 单一职责原则
2.2.1 引言
一个优良的系统设计,强调模块间保持低耦合、高内聚的关系,在面向对象设计中这条规则同样适用,所以面向对象的第一个设计原则就是:单一职责原则(SRP,Single Responsibility Principle)。
单一职责,强调的是职责的分离,在某种程度上对职责的理解,构成了不同类之间耦合关系的设计关键,因此单一职责原则或多或少成为设计过程中一个必须考虑的基础性原则。
2.2.2 引经据典
关于单一职责原则,其核心的思想是:
一个类,最好只做一件事,只有一个引起它变化的原因。
单一职责原则可以看作是低耦合、高内聚在面向对象原则上的引申,将职责定义为引起变化的原因,以提高内聚性来减少引起变化的原因。职责过多,可能引起它变化的原因就越多,这将导致职责依赖,相互之间就产生影响,从而极大的损伤其内聚性和耦合度。单一职责,通常意味着单一的功能,因此不要为类实现过多的功能点,以保证实体只有一个引起它变化的原因。
因此,SRP原则的核心就是要求对类的改变只能是一个,对于违反这一原则的类应该进行重构,例如以Façade模式或Proxy模式分离职责,通过基本的方法Extract Interface、Extract Class和Extract Method进行梳理。
2.2.3 应用反思
我们以一个常见的数据库管理系统为例来进行说明,通常情况下根据不同的权限进行数据删改查的系统比比皆是,然而正是这样一个比较的常见的需求场景,却存在着很多充满臭味的设计。一个违背SRP原则的设计看起来如图2-1所示。
图2-1 违背SRP的设计
在以下设计中,DBManager类对数据库的操作和用户权限的判别封装在一个类中实现,一添加记录为例,其实现逻辑可以表示为:
public void Add()
{
if (GetPermission(m_id) == "CanAdd")
{
Console.WriteLine("管理员可以增加数据。");
}
}
这显然是一个充满了僵化味道的实现,如果权限设置的规则发生改变,那就必须重新修改所有的数据库操作逻辑,在成千上万代码中搜索有可能带来隐患的代码,你必须选择将这种代码扫地出门。
在此,权限判断的职责和数据库操作的职责被无理的实现在一个类中,权限的规则变化和数据库操作的规则变化,都有可能引起DBManager修改当前代码。按照单一职责原则,一个类应该只有一个引起它改变的原因。所以我们选择以合适的方式来重构有缺陷的设计,在此显然可以通过实现一个Proxy模式来解决职责交叉的窘境,修改之后的设计思路如图2-2所示。
图2-2 职责分离的设计
以Proxy模式调整之后,有效实现了职责的分离,DBManager类只关注数据操作逻辑,而不用关心权限判断逻辑,在此仅以Add操作为例来说明:
public class DBManager : IDBAction
{
private string m_id = string.Empty;
public DBManager(string id)
{
m_id = id;
}
IDBAction Members#region IDBAction Members
public void Add()
{
// 执行数据增加
}
public bool Delete()
{
return false;
}
public void View()
{
throw new Exception("The method or operation is not implemented.");
}
#endregion
}
而将权限的判断交给DBManagerProxy代理类来完成,例如:
public class DBManagerProxy : IDBAction
{
private IDBAction dbManager;
public DBManagerProxy(IDBAction dbAction)
{
dbManager = dbAction;
}
public string GetPermission(string id)
{
return string.Empty;
}
IDBAction Members#region IDBAction Members
public void Add()
{
if (GetPermission("") == "CanAdd")
{
dbManager.Add();
}
}
public bool Delete()
{
throw new Exception("The method or operation is not implemented.");
}
public void View()
{
throw new Exception("The method or operation is not implemented.");
}
#endregion
}
通过代理,将数据操作和权限判断两个职责分离,而实际的数据操作由DBManager来执行,此时客户端的调用变得非常简单:
public class DBClient
{
static void Main(string[] args)
{
IDBAction dbManager = new DBManagerProxy(new DBManager("CanAdd"));
dbManager.Add();
}
}
在该例中,接口IDBAction其实实现了设计模式的另一个重要原则:依赖倒置,对此我们在后文有详细论述。在本例中,通过DBManagerProxy代理类实现了职责分离,DBManager类将仅有一个变化的原因,那就是数据操作的需求变更;而权限的变更和修改不对DBManager造成任何影响,体现了单一职责原则的基本精神。
2.2.4 规则建议
关于单一职责原则,我们的建议是:
l 一个类只有一个引起它变化的原因,否则就应当考虑重构。
l SRP由引起变化的原因决定,而不由功能职责决定。虽然职责常常是引起变化的轴线,但是有时却未必,应该审时度势。
l 测试驱动开发,有助于实现合理分离功能的设计。
l 可以通过Façade模式或Proxy模式进行职责分离。
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/zhongjiekangping/archive/2009/11/18/4827200.aspx
开放封闭原则
对于抽象层次来说,它是一个系统的本质的概括是系统的商务逻辑和宏观的,战略性的决定,是必然性的体现;具体的层次则是与实现有关的算法和逻辑,一些战术性的决定,带有相当大的偶然性。传统的过程性系统设计办法倾向于使高层次的模块依赖于低层次的模块;抽象层次依赖于具体层次。这实际上就是微观决定宏观,战术决定战略,偶然决定必然。依赖倒转原则就是要把这种错误的依赖关系倒转过来。
许多的建构设计模型,例如COM,CORBA,JavaBean,EJB等,它们背后的基本原则就是DIP。
对于软件设计的两个目标,复用和可维护性来说,传统的设计侧重于具体层次模块的复用和可维护,比如算法,数据结构,函数库等等。但是对系统的抽象是比较稳定的,它的复用是很重要的,同时,抽象层次的可维护性也应当是一个重点。就是说DIP也导致复用和可维护性的“倒转”
我们现在来看看依赖有几种,依赖也就是耦合,分为下面三种:
----- 零耦合(Nil Coupling)关系,两个类没有依赖关系,那就是零耦合。
----- 具体耦合(Concrete Coupling)关系,两个具体的类之间有依赖关系,那么就是具体耦合关系,如果一个具体类直接引用另外一个具体类就会发生这种关系。
-----抽象耦合(Abstract Coupling)关系,这种关系发生在一个具体类和一个抽象类之间,这样就使必须发生关系的类之间保持最大的灵活性。
DIP要求客户端依赖于抽象耦合,抽象不应当依赖于细节,细节应当依赖于抽象(Abstractions should not depend upon details. Details should depend upon abstractions),这个原则的另外一个表述就是"四人团"强调的那个:要针对接口编程,不要对实现编程(Program to an interface, not an implementation),程序在需要引用一个对象时,应当尽可能的使用抽象类型作为变量的静态类型,这就是针对接口编程的含义。DIP是达到"开-闭"原则的途径。
要做到DIP,用抽象方式耦合是关键。由于一个抽象耦合总要涉及具体类从抽象类继承。并且需要保证在任何引用到某类的地方都可以改换成其子类,因此,LSP是DIP的基础。DIP是OOD的核心原则,设计模式的研究和应用都是用它作为指导原则的。DIP虽然强大,但是也很难实现。另外DIP是假定所有的具体类都会变化,这也不是全对,有些具体类就相当稳定。使用这个类的客户端就完全可以依赖这个具体类而不用再弄一个抽象类。 (引用到此结束)
对于接口以及接口的作用,让我们用一个类比来理解,这样会更加的直观,我们平时用的插座就可以看做一种接口,我们只通过它就可以用电了,假若供电方式发生了变化,比如由现在的火力发电变为太阳能发电,整个供电线路要进行全面的改修,那麽我们的用电方式并不会受到影响还是通过插座来用电,供电方式发生的变化和线路的改变对我们来说是透明的,这样作的好处通过对比一下下面的情形就可以知道了,假若我们没有通过插座来用电,而是直接与供电站直接通过电线连接,除去安全性的问题不说,若供电方式发生了变化,线路要进行改修,那麽可能就会有人敲你家的门说:“你好,我们是来改装电线的”,而且可能是在凌晨2:00,为什么?城市的每一户人家都要进行这样的改装啊,电路改装人员的工作量实在是太大了,只能7*24的工作了。所以还是打开门吧,否则只能过着没有电的日子了。所以我们通过插座(接口)带来的好处是不是很明显了呢?它降低用电方和供电方的耦合,为变化的实施带来了便利。
接口是实现插件化(pluggability)的关键,对象间的连接不必硬绑定(hardwire)到一个具体类的对象上,而是绑定在一个较高层次的抽象之上(接口或者抽象类)因此增加了类的灵活性,可以自由的进行“插拔”。通过接口或抽象类可以降低类之间的耦合,一个对象可以很容易地被(实现了相同接口的)的另一个对象所替换,而不会影响这个对象本身,所以一切的变化完全在此对象不知情的情况下进行。