这条原则又叫高内聚性(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是不明智的。这也是敏捷开发一贯的作风，对敏捷开发的其他原则也是这样。