最近看了很多代码，想起写代码的一个有趣的地方就是实现相同的功能，修复相同的bug，不同的程序员可以用风格不同，甚至工艺也不一样。虽然最终都是可行的，但从结果主义的角度来看，对用户来说是一致的。我们可以称这种差异为个人品味。品味有好有坏，但如何评价有时很难有一个清晰准确的定义标准。一般来说，代码越简单明了，就越容易测试。Thebetter,butSimple,clearandeasytotest是标准的另一个维度，它会导致差异。如果真的是认真的，还可以无穷无尽，走的更远。我有一个小例子，大家可以根据自己的经验来分优劣。只要UserSession涉及到用户登录的app，就一定有一个UserSession类，它记录了所有与用户相关的数据和行为，并在用户退出时销毁。UserSession一旦创建，就是一个大部分业务模块都需要访问的实例对象。其他类如何访问UserSession，或者UserSession是如何传递给各个类的，有很多种方法。问题：ControllerA、ControllerB、ControllerC都需要访问UserSession实例，如何传递？方法一：在init方法中构造所有Controller并传入UserSession中，然后在内部持有一个strong属性。类结构如下：如果使用this方式，所有需要引用UserSession的地方都需要通过init传入，包括View、Presenter等Controller内部的对象，View还可能有子View，以树状结构分层，UserSession会出现在每个Class的init方法内。方法二：方法传参Controller本身不持有UserSession的实例，每个需要UserSession的方法都作为参数传入，如下图：相比方法一，UserSession会出现在每个方法的参数中更多的地方。显然，不持有强属性有它的好处，比如不会出现Controller不能释放，UserSession不能销毁的情况。UserSession和Controller的依赖关系也比较清楚，看.h中的方法就一目了然了。此外，当需要测试一个方法时，它更容易，完整的上下文包含在方法声明中。方法三：直接在.m文件里面持有Controller，通过另一个UserMgr实例统一获取UserSession，如下图：这样在.h中是看不到Controller和UserSession的关系的，通过.m中的另一个类（xxxMgr、xxxFactory、xxxService）获取UserSession实例。好处是.h文件比较干净，但是.m中可能到处都有获取UserSession的代码。一旦代码量太大，就很难理清Controller和UserSession之间的依赖关系。以上三种方法我都看过，不同的方法对代码的影响是不同的。这是一个典型的例子。一个完整的App中往往会有多个像UserSession这样的对象需要在多个地方被引用。三种方法最后都不行。影响功能的正常实现，但在代码阅读和维护上存在一些差异。
