学步园

这条原则又叫高内聚性(cohesion)原则,以前我们在面向过程时代提倡模块应该是:高内聚,低耦合(当然这条原则几乎是软件设计的根本原则).
所谓职责，我们可以理解他为功能，就是设计的这个类功能应该只有一个，而不是两个或更多．也可以理解为引用变化的原因，当你发现有两个变化会要求我们修改这个类，那么你就要考虑撤分这个类了．因为职责是变化的一个轴线，当需求变化时，该变化会反映类类的职责的变化．
比如我们要设计一个类，这个类需要从数据库中取出一个人的姓名等基本信息．根据用户的要求修改后再保存到数据库中．这个类基本上是做数据为开发人员每天必须面对的

interface Person
{
   public void ConnectDB();
   public void DisConnectDB();
   public DataSet GetPersonInfo();
   public bool SavePersonInfo();
   ..
}

实际上我们看到了，上面这个类(接口)实际上引起他变化的原因有两种了，一个是数据库的变化，一个是保存用户信息的规则发生变化．我们应该把这两部分适当的分离开来．

interface DBManager
{
   public void ConnDB();
   public void DisConnDB();
   //other DB Functions;
   //,
}

abstract class PersonInfo
{
   public DataSet GetPersonInfo();
   public bool SavePersonInfo();
   private DBManager dbm;
   public PersonInfo(DBManager paramDbm)
    {
        dbm=paramDbm;
    }
    
}

interface PersoManager
{
   public DBManager   dbm;
   public PersonInfo  pi;
}

实际上看起来PersonManager又违反了SRP原则，不过因为没有人会依赖于他，我们已经可以很好的复用DBManager和PersonInfo两个类了．

多个职责一定就要被分开吗？也不一定，当应用程序的变化方式总是导致这几个职责同时变化，那么就不必分离他们。换句话说，只有变化实际发生时职责才有真正的意义，如果没有征兆，就去应用SRP是不明智的。这也是敏捷开发一贯的作风，对敏捷开发的其他原则也是这样。