原则1-单一职责原则

我想写一个计算器，用经典的mfc吧，因为界面和功能都很简单，所以我直接在dlg（UI类）里实现了加、减、乘、除等逻辑运算。ok可以使用了。过了一阵子，我想让他在linux上跑起来，额，不能用mfc了，用qt吧，所以直接重新设计了一下ui，然后把加、减、乘、除等函数拷贝粘贴到新项目中。在以后的时间里，不断的更新ui使其不过时。因为逻辑实现放在了ui类里，所以每次更新ui都有可能误操作逻辑运算，可维护性哪去了？并且如果我又想移植到ios上开发，是不是还要拷贝加、减、乘、除等函数？可复用性哪去了？以上例子就违背了单一职责原则；

 

单一职责原则：对于一个类，应该有且只有一个导致它变更的原因，接口或函数方法的设计也遵循此原则；

 

有一个类opt，它有两个职责，opta和optb，在后期的维护过程中，你可能因为职责opta发生改变去修改opt类，这个过程中你很有可能误操作修改变了optb职责。这时候创建两个类opt1和opt2，分别负责opta和optb这两个职责，哪个职责发生改变对应修改哪个类就好，可维护性和可复用性都相对提高了。

 

因为职责划分粒度原因，一个类可能在设计的过程中或后期维护的过程中（职责扩散）不仅仅负责一个职责，这时可以继续拆分类，保证类级的单一职责原则；也可以用函数对职责进行拆分，保证函数方法级的单一职责原则；或者在函数方法内使用条件判断语句对职责进行拆分，但是要记住，在职责扩散到我们无法控制的程度之前，立刻对代码进行重构。