最近看了不少代碼，想起寫代碼有意思的地方之一在于，實現同一個 feature，修復同一個 bug，不同程序員可以寫出風格迥異的代碼，甚至流程也不同，雖然最后都可行，從結果論的角度對用戶來說是一致的。我們可以稱這種差異為個人 taste，taste 有好壞高低之分，但有時候如何評定卻很難有一個清晰準確的界定標準，一般來說代碼是越簡單越清晰越容易測試越好，但簡單清晰容易測試又是另一個維度的標準，又會產生分歧，真要較真起來可以無窮無盡越扯越遠。

我有個小例子，大家可以按自己的經驗來分個優劣。

UserSession

只要涉及用戶登錄的 App，都少不了有個 UserSession 的類，記錄和用戶相關的一切數據和行為，并在用戶登出的時候做銷毀。UserSession 是一個一旦創建之后，大部分的業務模塊都需要訪問的實例對象，其他 class 如何訪問 UserSession，或者說 UserSession 如何傳遞到各個 class，這里面的做法就多了。

問題：ControllerA，ControllerB，ControllerC 都需要訪問 UserSession 實例，如何傳遞?

方式一：構造傳遞

所有的 Controller 在 init 方法里都傳入 UserSession，之后再內部持有一個 strong property，類結構如下圖：

如果使用這種方式，所有需要引用 UserSession 的地方都需要以 init 的方式傳入，包括 Controller 內部的 View、Presenter 等對象，View 可能還有子 View，層層疊疊以樹形結構，UserSession 將出現在每一個相關 Class 的 init 方法之內。

方式二：方法參數傳遞

Controller 本身并不持有 UserSession 的實例，每個需要用到 UserSession 的方法以參數傳入，如下圖：

這種方式相較方式一，UserSession 作為每個方法的參數將出現在更多的地方。顯然，不持有 strong property 有他的好處，比如不會出現 Controller 無法釋放導致 UserSession 也無法銷毀的情況。UserSession 和 Controller 之間的依賴關系也更清楚，看 .h 中的方法就一目了然。另外需要測試某個方法的時候，要比較容易，方法的聲明里就有完整的 context。

方式三：內部直接持有

Controller 在 .m 文件內部通過另一個 UserMgr 實例來統一獲取 UserSession，如下圖：

這種方式在 .h 中看不出 Controller 和 UserSession 的關系，在 .m 中通過另一個類(xxxMgr、xxxFactory、xxxService)來獲取 UserSession 實例。好處是 .h 文件干凈一些，但 .m 中可能各處都有獲取 UserSession 的代碼，一旦代碼量多了之后很難理清 Controller 和 UserSession 二者之間的依賴關系。

以上三種方式我都見到過，不同方式對代碼的影響也不同，這是個典型的例子，一個完整 App 里往往有多個類似 UserSession 需要被多處引用的對象，三種方式最后都不會影響功能的正常實現，但在代碼閱讀維護上存在一些差異。