拆分代码与泛型

递减，用尽一切潜力的秘密。

社会的发展，人们对软件有了越来越多的期待。为了更快更好的把 APP 开发出来，开发者们越来越重视代码的可测试和可复用。开发者们把优良实践经验总结成各种设计模式。而软件架构的设计与开发，也是以此为根本出发点。

我们知道， MVVM 也好， VIPER 也罢，目的只有一个，把 VC 的代码分拆，使代码更容易测试和复用。

那么，抛开各种先进设计不谈，我们来聊聊代码分拆的基本做法是怎样的。

类内的代码拆分
1 把一个方法里的部分代码移到新建方法中。

2 根据所移代码，在方法名里补充需要的参数。

3 在代码原来的地方引用新建的方法。

至此，完成了文件内的代码拆分。后面我们尝试把方法移出文件。

代码分离到新类
4 新建一个类，把之前新建的方法移到新类中，在头文件把方法名加上作为对外接口。

5 在旧类中创建一个新类的对象。

6 把旧类中引用新方法的地方里的"self"，改为新类对象。

至此，完成了代码从一个类移动到另一个类。

原始的“换类不改类”
如果我们希望修改方法实现的功能，怎么办？

按传统做法，在旧类里直接改。把代码从旧类移到新类后，只需要修改新类，旧类无需修改。这在某种程度上实现了模块化。

但是，不管在旧类上改代码，还是在新类上改代码，只要改变原类代码，就破坏了每个类原有的“单一职责”。随时业务需求的变化，一个类不断修改代码，这个类的“职责”也就一直在变化。

我们希望每个类都有它自身的“单一职责”，在我们需要其它“职责”时，创建新的类，而不是去破坏旧的类，使其身兼数职或职责不断在变化。

于是，新的需求就应此而生：通过换类来实现功能的修改，而不是改类。

我们先创建第二新类，提供接口，并实现功能的修改。在旧类里创建第二新类对象。然后，把调用第一新类方法的地方，把第一新类对象改为第二新类对象。

至此，完成了最原始的“换类不改类”。

泛型，实现类职责的永久单一
随着功能的扩展，如果继续沿用上面的设计，我们在不得不在旧类上创建大量的新类对象，同时还得把旧类中引用的新类对象方法的地方一一找出并修改。

为了彻底做到“不修改旧类代码即可修改功能”的设计目标，我们对代码的设计进一步优化。

7 创建一个协议。

8 在旧类中创建一个协议对象 (id<protocol>)。把旧类中调用新类方法的地方全部改为调用协议对象方法。

9 创建一个符合协议的新类。在协议新类的协议方法里完成旧类功能的实现。

10 在旧类实例化的地方，把协议新类实例化，赋给旧类的协议对象。

11 把旧类引用新类对象方法的地方，改为引用协议对象方法。

12 以后需求变化，修改功能，只需要把第二协议新类实例化后，赋给旧类的协议对象就可以。其它任何地方的代码全都无需改变。

这样就可以把一个类的变化部分，彻底分离出来，让一个类的职责永保单一。

后记(下面以聊家常为主，没时间没兴趣的朋友请直接忽略)：

递减原则
昨天，发布了《从零开始学 iOS 开发的 15 条建议》，最开始只是为了避免有人重复问我“怎么自学 iOS 开发”这个问题。

今天，我完成了 6 组共 300 个仰卧起坐。在健身的时候，因为越做到后面的组别时，保持每组 50 个越来越困难，使得不敢轻易开始新的一组。那么，我少做一组就少做 50 个。如果我没有一组做 50 个的规则，那么我将可以非常轻松地多做 10 个。

由此可见，“定量思维”会极大的降低人的潜力。“倒金字塔”或“递减”思维，更有利于把潜力榨光。

《 15 条建议》里，项目、源码、书籍、博客、文档、视频、社区、搜索、Ｑ群，这样由难而易的学习顺序，明显就是一种“递减思维”。递减式的学习顺序可以适合所有人。任何人按着这个顺序来，永远有事可做。而递增式的学习顺序则会让有积累的人到超级无聊。

所以我应该改变我的健身组合，一开始尽可能地多做，然后每次根据当下的情况递减，理想情况是递减到 1 个都做不下。

同样的，不管我做任何事，都应该用“递减原则”代替“递增原则”，让自己和世界的潜力得到最大的互动。

我们对待儿子的方式，就是递减式的。从来不会只在对应年龄段给儿子找书看，而是先把书丢给他，如果他看得吃力或不感兴趣，再换一本低一年龄段的。

我将通过“递减原则”全面改造我现在第 138 版的人生系统：《疯子一般深入系统》。