设计模式之单一职责原则（iOS开发，代码用Objective-C展示）
单一职责原则：就一个类而言，应该只有一个引起它变化的原因。
在iOS开发中，我们会很自然的给一个类添加各种各样的功能，比如随便写一个简单的应用程序，一般都会生成一个viewController类，于是我们将各种各样的代码，商业运算的算法、http请求的参数(params)封装、使用FMDB、coreData时的数据库访问语句都放在这个类里面，这就意味着，无论任何需求变化，都要来修改viewController这个类，这其实是很糟糕的，维护麻烦、复用不可能、缺乏灵活性。
也许上面说的略微夸张，因为只要是稍微有iOS开发经验的朋友都知道，在iOS开发中，是采用MVC模式的，数据处理、封装放入model中，视图展示、操作放入view中，而controller只是负责将model提供的数据展示到view上去。从而保证各个模块各自独立、分工明确，容易维护。
但仅仅只是这样还不够，像发起http请求的代码、各种逻辑业务的代码、使用数据库做离线缓存的代码，与view\model无关，难道就全部放在controller里面？如果这样做，那controller里面代码将非常多，且杂乱。
就比如说，实现一个iphone上的俄罗斯方块游戏（请勿完全参照图片）：
- 方块形状有不同的种类，需要代码生成
- 各方块在下落的时候，应该是通过动画下落，左右平移也应该是通过动画，并且还需要控制每次下落一格的时间，随着时间的推移（玩家等级的提高），格子单位时间下落的行数是不同的
- 在什么时间碰触到底部的方块？碰触到了该怎样停止运动？停止运动后，该不该消除这一行？等
如果将上面提到的这些全部写在一个viewController里面，这是非常不合理的，代码复用性也很差。
所以需要将之分离出来，上面提到的三点，1和3是和游戏逻辑相关的，和界面控制以及如何展示并没有多大联系，为什么要写到ViewController里面？正确的关系应该是这样的，用一个类来生成不同种类的方块，一个类来控制方块的动画，一个类来控制方块的平移、碰撞等操作。这样就可以就各个与界面逻辑无关的业务逻辑抽出来，将来如果要维护，只需要找到对应的类的功能区修改即可，而不需要改动viewController里面的东西。
如果一个类的职责过多，就等于把这些职责耦合在一起了，一个职责的变化可能会抑制或者削弱这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受意想不到的破坏。
软件设计要做的许多内容就是发现职责，并把那些职责相互分离。其实要去判断是否能分离出类来，也不难，如果可以想到多于一个动机去改变一个类，那么这个类就具有多于一个的职能，这个时候就该考虑职责分离。总的来说，在编程过程中，我们要在类的职责上多思考，做到单一职责，这样的代码才是易维护、易扩展、易复用、灵活多样的。
