🚏 导论
单一职责原则（SRP），就一个类而言，应该仅有一个引起它变化的原因。
如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。
软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，就应该考虑类的职责分离。
🎬 场景
场景一：📱 手机
现在的手机都有很多功能（除了打电话、发消息）：听音乐 、玩游戏、 拍照、摄影等等。但是这里的功能，都是基础功能，实际并没有做的特别专。比如听音乐，手机的音质没有专业的音乐播放器好；拍照，手机的像素没有专业的相机好；玩游戏，手机的操作体验没有专业的游戏机好。所以，手机的功能虽然多，但是都是基础功能，没有做的特别专业。大多时候，一件产品简单一些，职责单一一些，或许是更好的选择。
当然，手机的发展有它的特点，而编程时，我们却是要在类的职责分离上多做思考，做到单一职责，这样代码才是真正的易维护、易扩展、易复用、灵活多样。
场景二：♦️ 俄罗斯方块
俄罗斯方块的实现：俄罗斯方块下落动画的原理是画四个小方块，擦掉，然后再在下一行画四个小方块。不断绘出和擦掉就形成了动画，所以应该要有画和擦方块的动画。然后左右键实现左移和右移，下键实现加速，上键实现旋转，这些其实都应该是函数，当然左右移动需要考虑碰撞的问题，下移需要考虑堆积和消层的问题。
这里大部分都是一些函数，如果将这些函数都放在一个类里，那么这个类就会变得很大，很难维护并且也很难迁移。可以将这些与游戏逻辑相关的函数（下落、旋转、碰撞判断、移动、堆积）提取出来，这些函数和界面如何表示没有特别大的关系，因为所谓方块无非是一个坐标，方块的下落、旋转、碰撞判断、移动、堆积等都是坐标的变化。因此可以将运行界面和游戏逻辑分开，这样就可以更好的维护和迁移。