所谓单一职责原则，敏捷软件开发中的定义是：就一个类而言，应该仅有一个引起它变化的原因。这里的职责指的就是变化的原因。也就是说一个类中如果它含有2种以上能引起变化的原因，那么它就违反了单一职责原则。
interface IBeMan
{
public void BeBoyFriend();
public void BeHusband();
}
如果这个类代表的意义是，“一个男人有可能会成为某人的男朋友（BoyFriend），也有可能成为某人的丈夫（Husband）。”的话。按照通常的世俗观念，人们不允许一个男人既“BeBoyFriend”又“BeHusband”，就算现在的确有这种现象，那是因为他们不是程序员，也没有学过单一职责的原则，这里不再做评。大多数人的做法应该立即将其分离开来,分别生成新的接口IBeforeMarry和IAfterMarry。找准自己的定位和角色。
interface IBeforeMarry
{
public void BeBoyFriend();
}
interface IAfterMarry
{
public void BeHusband();
}
这样既符合了世俗的观念又符合了单一职责的原则，何乐而不为呢？！
但是并不是所有的职责都需要进行分离，比如：一个类可能具有了多个职责，但是它本身不可能总变化，那我们就可以不对其进行重构。学习的目的是为了合理运用而不是滥用，所有的方法都提取和分离的方法并不科学，还是要看清本质和具体情况，认为的确有必要再做处理才是该提倡的。
再来个例子：
interface IBeMan()
{
public void BeSon();
public void BeFather();
}
每个男人都会有一个身份，那就是儿子（Son），理想状态每个男人也都会成为父亲（Father），这两者并不冲突，而且也应该是每个男人应有的角色，所以没有必要非要将这两个职责分离。
以上例子未必准确，只是为了方便理解。仅此而已。
