update: refactory single_responsiblity_principle

docs/content/design_principles/open_closed_principle.md

@@ -2,22 +2,26 @@
 
 开闭原则，The Open-Closed Principle，简称 OCP，是指软件实体（类、模块、函数等）应该可以扩展，但是不可以修改。即对于扩展是开放的，对于更改是封闭的。通俗来说就是对于要增加的新功能或要调整的改动，尽量扩展新代码而不是修改已有代码。
 
+**使用动机**
+
+面对需求改变可以保持相对稳定，使得系统可以在第一个版本以后不断推出新的版本。
+
 **如何使用**
 
 通过对以下可能时机的变化，创建抽象，隔离以后发生的同类变化。
 
-- 在开发工作展开前预测可能的变化
+- 在开发工作展开前预测可能的变化。
 
-- 或展开不久后知道可能发生的变化
+- 或展开不久后知道可能发生的变化。
 
-- 或当实际需要发生时带来的变化
+- 或当实际需要发生时带来的变化。
 
 **使用原则**
 
 - 仅对程序中呈现出频繁变化的部分做出抽象。
 - 不要刻意对每个部分进行抽象，拒绝不成熟的抽象，它和抽象本身一样重要。
 
-**示例**
+**使用示例**
 
 以一个加法器为例。
 

docs/content/design_principles/single_responsiblity_principle.md

@@ -1,26 +1,31 @@
 # 单一职责原则
 
-## 1 概念
+单一职责原则，The Single Responsibility Principle，简称 SRP，是指就一个类而言，应该仅有一个更改它的原因。也即这个类只有一个职责。
 
-单一职责原则，全称The Single Responsibility Principle，简称 SRP，是指就一个类而言，应该仅有一个更改它的原因。也即这个类只有一个职责。
+**使用动机**
 
-## 2 知识点
+若不遵守单一职责原则，即一个类有一个以上的职责，则当一个职责发生变化时，可能会影响其他职责，从而影响代码的维护。
 
-**单一职责的原因**
+**如何使用**
 
-若不遵守单一职责原则，即一个类有一个以上的职责，则当一个职责发生变化时，可能会影响其它职责，从而影响代码的维护。
+核心在于职责的分解。需要将相同的职责放到一起，不同的职责分开到不同的类的实现中去。具体来说，对于一个类，如果能想到多于一个的动机去改变一个类，那么该类具有多于一个的职责，应该考虑将类的职责分解。
 
-**单一职责的优点**
+**使用原则**
 
-- 类的复杂性降低，每一个类实现的职责有清晰明确的定义；
+- 每一个类实现的职责有清晰明确的定义。
+- 一个类的修改只对自身有影响，对其他类没有影响。
 
-- 可读性高，当类的复杂性降低，可读性自然提高；
+**使用示例**
+
+以一个俄罗斯方块游戏为例。
+
+最直观的想法是，用一个计时器控制动画，每一个计时器编写绘制和擦除方块的逻辑，模拟下落时方块形状的变化，再做一个堆积和消层的判断，最后提供键盘控制逻辑。
+
+假设我们一开始做的是 Web 游戏，游戏效果不错后需要增加 3D 版、手机版等。此时，相对变化的只有方块的样式，但由于我们的代码都在一块，导致其他不变的逻辑没法复用。这就是职责过多的情况，接下来考虑如何将职责分解。
+
+最简单的方法就是将变化的和相对不变的部分分开，也就是将游戏的逻辑（不变的部分）和界面的展示（易变的部分）分开。具体来说，可以将游戏区域设计为二维数组，通过坐标来表示每个方块，实际显示出的方块就是坐标值为 1 的方块。这样，就可以通过值为 1 的坐标的变化模拟出方块的堆积和变换。也就是说，游戏的操作和判断逻辑（如变换、移动、堆积、消层等）其实就是坐标值的变化。界面的展示只是根据数组数据进行绘制。
 
-- 可维护性提高，可读性的提升会带来可维护性的提升；
 
-- 变更引起的风险降低，变更是不可避免的，若类遵守单一职责原则，则一个类的修改只对自身有影响，对其它类没有影响，这大大降低了变更带来的风险。
 
-**单一职责的使用**
 
-核心在于职责的分解。需要将相同的职责放到一起，不同的职责分开到不同的类的实现中去。具体来说，对于一个类，如果能想到多于一个的动机去改变一个类，那么该类具有多于一个的职责，应该考虑类的职责分解。