什么是单一职责
单一职责原则（Single responsibility principle，简称SRP），顾名思义，是指一个类或者一个模块应该有且只有一个职责，它是面向对象编程六大原则之一。
单一职责的粒度
单一职责的粒度，可以是某个方法、某个类、某个程序包甚至某个功能、某个模块（甚至某个系统），每一个层次上都可以进行单一职责设计。下面来举个例子说明一下：
模块级别：某购物平台，包含如下几个模块：用户模块、商品模块、订单模块、库存模块、运输模块、支付模块，每一个模块都已本身的职责：用户模块负责用户相关的功能，商品模块负责商品的管理等等；
功能级别：在模块内部，比如用户模块，根据用户相关职责划分，又划分为用户管理、注册、登录等不同的功能，他们的职责也都是各不相同的；
程序包级别：在用户管理中，又可以根据层次不同划分为持久化层、业务逻辑层、UI层，其中每一层基本上就是一个程序包，持久化层负责数据持久化相关（和数据库打交道，数据的CRUD（增删改查）），业务逻辑层负责用户管理相关的业务逻辑（比如修改密码），UI层负责用户界面交互；
类级别：在持久化层内部，又可以根据职责不同划分为：数据库连接类（负责数据库连接的构造）、持久化类（负责数据的CRUD操作）、数据缓存类（负责数据缓存的处理）等；
方法级别：在持久化类中，又可以划分为查询数据方法（负责查询数据）、检索数据方法（负责检索数据）、新增数据方法（负责插入数据）、 删除数据方法（负责删除数据）、修改数据方法（负责修改数据）。有些复杂场景，甚至建议增删改查每一个逻辑都放到不同的类中；
方法级别二：在查询数据方法中，又可以根据查询的逻辑步骤划分为不同的二级方法：解析查询条件方法、构造Sql方法、执行Sql方法、构造返回实体方法；每个方法可以借着这个思路再往下细化；
单一职责的优点
- 增强功能的稳定性
单一职责能够增强功能稳定性、健壮性，适应程序的变化，避免修改一段逻辑时，对其他逻辑造成影响。例如：一个类或者一个方法，承担了多个职责：职责A、职责B、职责C...职责N。如果在维护过程中，修改之职责A对应的逻辑，就很有可能对职责B、C等其他职责逻辑造成影响，最终不利于功能的稳定性。 - 提升复用能力
使用单一职责，有一某一个类或者方法都是对应的它本身的唯一职责，已经是实现某个职责的最小粒度，所以它可以提供给任何需要该职责地方调用，从而提升了复用能力。 - 降低程序复杂度
由于单一职责原则是根据职责来设计，每一个类或者方法只实现某一特定的逻辑，粒度划分的合适的话，每一个类基本上只有几行、至多几十行代码，程序复杂度会被大大降低； - 提升可读性
每一个程序包、类、方法职责明确后，我们在阅读代码时，我们可以通过方法名就能知道某个方法是干什么的（可以不用知道具体的细节），它内部用到的方法是干什么的，有助于我们在某一层次上思考代码逻辑是否正确、完整，而不用受某一具体细节逻辑的影响。
具体实践
在用户管理持久化层，如果要适配不同类型的数据库（比如要支持SqlServer、Oracle、MySql等），不同类型的数据库，其语法结构都有一些差异，比如插入数据方法，插入sql的语法是不同的。我们可能按照如下代码实现：
以下是用户信息的结构：
public class UserInfo
{
public string ID { get; set; }
public string Code { get; set; }
public string Name { get; set; }
}
以下是用户持久化的新增数据方法：
public class UserDac
{
Database GetDatabase()
{
/*获取Database连接的逻辑*/
}
//新增用户
public void AddUser(UserInfo userInfo)
{
Database db = GetDatabase();
string insertSql = string.Empty;
switch (db.DbType)
{
case DBType.SqlServer:
insertSql = "Sql A";
break;
case DBType.Oracle:
insertSql = "Sql B";
break;
default:
throw new NotSupportedException("DBType");
}
db.ExecuteSql(insertSql);
}
}
在上面的例子中，我们看似应该是一个比较简单并且合理的结构。但是假如有以下需求场景：
1、我的业务中添加了新的字段，需要修改 InsertSql（在Sql中添加新字段部分）；
2、我需要添加一种新的数据库类型支持（假如需要支持开源的MySql），新的数据库类型中，Sql语法也是不相同的；
两个场景都需要修改以上的代码，这说明上面这段代码承担了两个职责，违背了单一职责原则。
从上面的方法中，我们可以看到 ，上面方法承担了两个职责：拼接插入Sql；适配不同的数据库类型。我们可以按照如下方式进行修改（修改中用到了设计模式中的策略模式）。
用户信息的结构不变：
public class UserInfo
{
public string ID { get; set; }
public string Code { get; set; }
public string Name { get; set; }
}
第一步：我们添加一个获取Sql的策略，如下结构：
public interface IUserSqlStrategy
{
string GetInsertSql(UserInfo userInfo);
}
第二步：我们添加SqlServer的策略实现：
public class SqlServerUserSqlStrategy : IUserSqlStrategy
{
public string GetInsertSql(UserInfo userInfo)
{
return "Sql A";
}
}
第三步：相应的，我们添加Oracle、MySql的的实现类：
public class OracleUserSqlStrategy : IUserSqlStrategy
{
public string GetInsertSql(UserInfo userInfo)
{
return "Sql B";
}
}
public class MySqlUserSqlStrategy : IUserSqlStrategy
{
public string GetInsertSql(UserInfo userInfo)
{
return "Sql C";
}
}
第四步，我们添加策略工厂，来根据不同的数据库类型获取不同的策略实现：
public class UserSqlStrategyFactory
{
public static IUserSqlStrategy GetUserSqlStragety(DBType dbType)
{
switch (dbType)
{
case DBType.SqlServer:
return new SqlServerUserSqlStrategy();
case DBType.Oracle:
return new OracleUserSqlStrategy();
case DBType.MySql:
return new MySqlUserSqlStrategy();
default:
throw new NotSupportedException("DBType");
}
}
}
最后，执行插入逻辑中，调用策略工厂获取策略，然后根据相应的策略获取不同的Sql实现：
public class UserDac
{
Database GetDatabase()
{
/*获取Database连接的逻辑*/
}
//新增用户
public void AddUser(UserInfo userInfo)
{
Database db = GetDatabase();
var strategy = UserSqlStrategyFactory.GetUserSqlStragety(db.DbType);
string insertSql = strategy.GetInsertSql(userInfo);
db.ExecuteSql(insertSql);
}
}
以上是所有的代码实现，通过策略模式，将不同数据库类型的实现拆分到不同的策略实现类中，这样拼接插入Sql逻辑与适配不同数据库逻辑两个职责拆分开来。
总结
通过单一职责原则，将程序实现拆分到不同的类（或者方法）中，这样，以后的变化都只影响要修改的主责，而不会影响到其他职责，最终达到提升稳定性的目的。
原文地址：https://www.cnblogs.com/silencer/p/10812466.html