第3章 设计原则—单一职责原则

3.4 单一职责原则

概念：就一个类而言，应该仅有一个引起它变化的原因。
我们在做编程的时候，很自然地就会给一个类加各种各样地功能，比如一个窗口应用程序，一般都会生成一个xxxDialog的类，于是我们就把各种各样的代码，像某种业务的业务算法，像数据库访问的SQL语句等都写在这个类当中。这就意味着，无论任何需求要来或者变化，你都需要更改这个窗体类，这其实很糟糕，维护很麻烦(因为这一个类(xxxDialog类)功能点太多，职责太多)，复用不可能(如果只想用业务算法或者SQL部分都不可能，因为它们都在一个类中，除非移植xxxDialog类中的部分代码，整体复用不现实，因为牵扯太多，无用的部分太多)，也缺乏灵活性(不能复用、替换该类、该类的业务算法功能、该类的SQL数据库访问功能，也不能快速替换某部分功能，因为使用了与某种模块绑定的具体函数，例如使用只针对oracle的连接、操作，想替换其他数据库则需要修改程序代码)。

一些和游戏有关的逻辑，和界面如何表示没有什么关系(业务逻辑实现和界面表现没有什么关系，界面可以换，业务逻辑类可以复用)，为什么要写在一个类里面呢？
如果一个类承担的职责过多，就等于把这些职责耦合在一起(如业务和界面实现放到一个类中，则这个类既要负责页面的交互又要负责业务的实现，每一种功能的变化都要修改这个类。后边提到面向接口编程，把业务和界面分开用接口交互，需求有变化，只需要修改具体做实现的子类即可)，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。

软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。
怎么去判断是否应该分离出类来？
如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，就应该考虑类的职责分离。比如，界面的变化是和游戏本身是没有关系的，界面是容易变化的，而游戏逻辑是不太容易变化的，将它们分离开有利于界面的改动(适用各种平台)。

职责的分离是可以把事情做得更好。整合当然是一种很好的思想，但要注意使用场景。
编程时，我们要在类的职责分离上多思考，做到单一职责，这样的代码才是真正的易维护、易扩展、易复用、灵活多样。