职责单一，一切设计原则的基石
要从复杂繁琐的业务中提取出职责单一的类须要按照特定的步骤分析，但在项目中成本的因素会省略跳过，最后系统无法复用没有弹性，不能遵循开闭原则。最终项目变成锤子系统。
问题来了，按照什么样的特定步骤分析才能找到职责单一的类呢？
首先要说的是找到职责单一的类不需要一个过程，有一定的成本，我们慢慢来先看以下大概步骤 ：
- 从业务中找到参与者得到对象
有这么一个游戏需求：我们玩石头剪子布的游戏，游戏规则是石头赢剪子，剪子赢布，布赢石头，两个张三和电脑(随机出拳)玩这个游戏谁先获取2分就是获得胜利。
以上的需求中的参与者：张三，电脑，石头，剪子，布，裁判(隐藏的参与者)。
当我们找到参与者以后即对象，游戏规则再怎么变，对象是稳定的一般不会变，这样以来我们的对象就可以复用。
- 确定对象之间的业务关系确定类的行为
把业务中的动作行为提取出来，再赋予给对象，确定行为后，其他我们就完成功能划分了，但在这个步骤里面还不能给开发人员做任务分配，因为依赖关系还没确定。
张三{出拳()}、电脑{出拳()}、石头{比大小()}、剪子{比大小()}、布{比大小()}、裁判{开始()}。
- 从对象集中抽象(抽取)共性得到类
张三、李四、都有出拳可以提取得到玩家父类{人子类，电脑子类}因为人与电脑都有出拳方法但它们的出拳方法的过程不一样;石头、剪子、布可以提取得到拳类;裁判对象得到裁判类。
玩成这第三步以后提取类的工作完成。
- 依据类的行为建立耦合关系，类关系图表示
最后我们再根据业务规则来建立耦合关系，裁判->玩家,裁判->拳,玩家->拳。
裁判依赖玩家、拳;
玩家依赖拳;
拳不依赖其他类;
建立耦合关系后我们就可以安排开发任务：
姓名 任务
张三 拳
李四 玩家
王五 裁判
以上遵循了依赖倒置原则，那么我们在开发过程中只要先完成抽象父类编码工作就可以贯通全项目，子类的编码进度是不会影响业务流程架构。我们的项目流程依赖父类串通连接。
以上又产生了两个问题：如何从业务中找到对象？如何为对象确定行为？如何避免一个对象的职责过于强大?
回答完这三个问题我们才可以真正找到职责单一的类
