软件设计原则--单一职责原则

1.单一职责原则（SRP--Single-Responsibility Principle）

SRP简介：就一个类而言，应该只专注于做一件事和仅有一个引起它变化的原因。

所谓职责，我们可以理解他为功能，就是设计的这个类功能应该只有一个，而不是两个或更多。也可以理解为引用变化的原因，当你发现有两个变化会要求我们修改这个类，那么你就要考虑撤分这个类了。因为职责是变化的一个轴线，当需求变化时，该变化会反映类的职责的变化。

为什么要使用单一职责原则呢？

我们在做编程的时候，很自然地就会给一个类加各种各样的功能，举个例子，比如我们写一个窗口程序，一般都会生成一个form1这样的类，于是我们就会加入很多功能代码，像数据库访问的sql语句等，这样就意味着，无论任何需求要来，你都要修改这个窗体类，代码混乱，维护麻烦、复用不可能，灵活性丧失。

上述解释如果没理解明白，那么我在举个例子，俄罗斯方块大家都玩过，如果使用winform的方式开发

 

 

 

按照这个思路，大家可能在开发的时候把所有的代码都写在这个窗口类里面了，这样是不可理的，为什么不合理，打个比方，我想在手机上运行这个游戏你怎么改，有人会说，把关键代码copy过去，再对其他的做一些改进；那你再想一想，这些下落、旋转、移动等游戏的逻辑部分改变了吗，答案是没有，这些逻辑和界面完全没有联系，那你为什么还写的一个类里面呢，如果一个类承担的职责过多，据等于把这些职责耦合起来，一个职责的变化可能削弱或抑制这个类完成其他职责的能力，这种耦合会导致脆弱的设计，当发生变化时，设计会遭到意想不到的破坏。所以我们应该把这些进行分离，方块的变化就是一个数组值的变化，而下落、旋转是在做这些数组值的变化，当有一天要改变界面或换界面的时候，只是窗体的变化。游戏逻辑部分无须改变，以此达到复用的目的

 

怎么判断是否应该分离出类来？

如果那你能想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，这时就应该考虑职责分离

 

使用SRP注意点：

1、一个合理的类，应该仅有一个引起它变化的原因，即单一职责； 

2、在没有变化征兆的情况下应用SRP或其他原则是不明智的； 

3、在需求实际发生变化时就应该应用SRP等原则来重构代码； 

4、使用测试驱动开发会迫使我们在设计出现臭味之前分离不合理代码； 

5、如果测试不能迫使职责分离，僵化性和脆弱性的臭味会变得很强烈，那就应该用 Facade或Proxy模式对代码重构；

SRP优点：

消除耦合，减小因需求变化引起代码僵化性臭味