项目组今天碰到了待办展示的问题：在目前的系统中分为计算类和提醒类两种待办，对两种待办应该给前台什么样的数据的问题上，意见达不到统一。前台的意见是：两种待办可以一起传入到一个list中；后台的建议是：两种待办必须分离展示，他们不是一个类型，即使在一个分类中，也应该分离成一个是提醒，一个是待办两种展示。结合前几天看的Robort C. Martion的《敏捷软件开发》一书中讲到的单一职责模式，此处讨论一下待办组件实现的方式。     单一职责原则（SRP）：就一个类而言，应该仅有一个引起它变化的原因。（如果程序变化总是导致两个职责变化的话，那就不应该分离他们）     例如：我们在写GUI代码的时候，绘制矩形的方法draw()和计算矩形面积的方法area()是不同的职责，在修改draw()方法来限制图像大小范围的时候不会影响到area()函数的变化，所以我们尽量的去分离类的职责，实现两个接口来完成任务。     待办的问题是单一职责的拓展的问题。计算类待办和提醒类待办实现了不同的接口，接口定义如下：     //计算类     public interface CalculatePendTask{      void int nums;//计算出有多少个待办需要处理；     }     //提醒类     public interface RemindPendTask{      void List pendTaskList;//返回提醒的待办的列表     }     不同的分类实现不同的接口后，由组件通过读取xml配置文件来确认返回给前台的待办数据。xml的具体配置如下：                    实现类的spring配置名称          鉴权的url          sms          是否是计算类待办          ……                      实现类的spring配置名称          鉴权的url          sms          是否是计算类待办          ……               我们返回给前台的json数据是一个category里面item的列表，如果是在这个配置文件中item的属性中的实现了不同的接口，其实返回给前台的list中就是有两种待办的信息，一个分类中的不同类型的待办展示在一起也是没有问题的，满足前台展示的需求。现在的问题是：我们是否应该把分类单一职责化？也就是说：category分类要么是计算类的待办，要么是提醒类的待办！     从用户体验角度，我支持分离的理由一：如果不分类的话，会让用户会产生有的提醒后面有数字，而有的后面没有的疑问（计算类待办告诉用户需要处理事务的个数，提醒类的仅仅一条数据提示），同时也没有较好的把待办的优先级分离开，一般提醒类待办的优先级高于计算类；理由二：如果分离待办分类的话会使结构更加清晰，一个category的title可以是“……提醒”，一个是“……待办”，让用户对要做的事情一目了然。     就一个类而言，需要一个引起他变化的原因；同理，对一个配置文件而言，也需要一个引起他变化的原因。提醒类待办一般是新加了业务线才会有引起变化，如果是各个业务线需要加新的提醒则是统一要添加上；而计算类待办由于各业务线的工作流程不一样，往往有较大差异，改动也较为频繁。同时，如果是item中的属性变化了，提醒类的待办需要统一变化，而计算类的可能就没有必要变化。在后续维护的过程中，也容易造成混淆，新手对xml配置中不同的item的属性是一头雾水，如果是两个分类放在一起的话，则有点把“draw()”和“area()”合并的味道。在修改一个分类属性的时候不一定会引起另外一个变化的情况下，我建议分离配置职责。