单一职责原则

单一职责原则 2.2 单一职责原则 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 } 而将权限的判断交给DBManagerProxy代理类来完成，例如: public class DBManagerProxy : IDBAction { private IDBAction dbManager; public DBManagerProxy(IDBAction dbAction) { dbManager = dbAction; } public string GetPermission(string id) { return string.Empty; } IDBAction Members } 通过代理，将数据操作和权限判断两个职责分离，而实际的数据操作由DBManager来执行，此时客 户端的调用变得非常简单: public class DBClient { static void Main(string[] args) { IDBAction dbManager = new DBManagerProxy(new DBManager("CanAdd")); dbManager.Add(); } }