最近在考項目管理的課程，學到了系統工程這一門課，有一些感觸和領悟，特在此記錄一下。

這些想法和下邊敘述的內容都是我個人在編程方面的一些想法，由于不善寫作，可能例子會比較少。有興趣的朋友，可以在評論區留言，我們做進一步的交流。

先說說我得出的結論：當我們使用系統的思想去處理程序，有很多令我疑惑的問題就迎刃而解了，我會圍繞這個思想一步一步的解釋，為什么系統的思想能夠解決困惑我的問題。

記得我剛開始學iOS那會，我們寫的最多的代碼就是tableView，我們從最簡單也最有問題的地方開始。我看到過很多初學者在寫cell的時候，直接在控制器中給cell添加各種各樣的控件，這會有很大的問題，當別人想復用這個cell的時候該是多么的痛苦。

顯而易見，上邊說的就是最低級的方式，甚至連MVC的概念也沒用到，好了，接下來我們用一個模型來封裝cell。這應該是當下iOS編程中使用最多的方式，cell和模型有很強的耦合關系。這種情況下的cell，往往使用一個獨立的文件創建，在初始化方法中創建控件，在模型的setter方法中配置控制。這里的配置就包含了賦值操作和根據模型中的屬性控制顯示方式的操作。

這么做符合mvc的概念，控制器和view之間通過模型作為連接的管道，同時也減少了view復用的代價。但這樣仍然有很多問題，知道了問題的所在，我們的架構才能夠進化：

根據業務的復雜程度，我們在模型的setter方法中，要處理的業務也會各不相同。原理上，界面如何顯示跟模型有極大的關系。雖然這種方式能夠正確顯示數據，但無法緩存frame。我會在后邊講到，為什么這種通過setter賦值的方式很不符合編程中的語義要求。

假如說cell中有一些控件是有點擊事件的，這些事件中需要發送網絡請求。有的人喜歡通過代理的方式把事件傳遞到控制器中，這么做的優點是能夠得到控制器這個對象，因此就能夠輕易的使用控制器的屬性，比如說添加加載控件到控制器的view上，或者使用控制器中的某個參數，但往往有點擊事件，就有數據更新，

依賴于模型setter方法的弊端就顯現了出來，你必須要先修改模型后，再去刷新tableview，此時此刻，我們就稱之為這個模型被污染了。

一種好的設計方案是，界面的顯示有一套模型，數據源是另一套模型，這種方案，我們馬上就會講到。

我見過那種把事件的邏輯直接寫到view中的，這樣做省卻了代理傳值的麻煩，且view基本上能保持功能的完整性。當我們在別的地方復用該view的時候，不需要在控制器中寫重復的代碼。缺點是無法獲取控制器屬性，即使能夠獲取控制器，也只有再把控制器屬性暴露在.h中才能使用，這就破壞了編程中的封裝性。

如果你的代碼中很少使用類似于readonly這樣的權限屬性，那么你就應該去學學這方面的知識，這不是一個屬性的事情，而是一種編程思想的問題。

說到這里，我們已經明白，使用模型的setter這種方式開發是一種常見行為，但是弊端也很明顯，它并不能成為一個拿得出手的技巧。我們接下來說說view model這一概念，我們簡稱為vm。vm可以算是model和view的一個中間過程，其實，編程的本質還是處理數據。在vm中我們通過model可以配置出view所需要的任何屬性，因此view得到解放，它不必關系這一過程是怎樣的，只需要拿到vm中的屬性直接顯示就行。

同理，vm還緩存了view中各個控件的frame信息。有的人可能會把vm叫做frame模型，這是不合理的，提供frame只是一個小小的功能，提供view直接顯示的信息才是它的核心功能。

舉個簡單的例子，有一個cell，上邊有3個label，我在使用vm的時候，根據模型計算出這3個label的attText，然后使用yylabel顯示數據，同時，在vm中計算label的frame，因此cell中的代碼就很干凈，簡單。這時候，vm就接管了cell的顯示任務，模型作為核心數據，不會被污染。

vm仍然有它的問題，跟新數據算是一個問題，時間的傳遞它也并沒有很好的解決。

上邊的兩種設計雖然有問題，但仍然需要使用，后來，我冒出來一種manager的想法。manager擁有提供和處理數據的能力，它很想一個超強大腦，能夠為view或者控制器提供任何想要的數據和功能。

想想一下，一個表單，有很多項需要填寫，manger可以提供一份默認值，可以保存編輯后的值，可以驗證數據是否合法，可以獲取參數字典等等，它都可以做到，因為這些數據就在它內部保存著，沒有誰比他更清楚這些東西。這在語義上是比較符合要求的，如果我們把這些復雜的需求保存在一個模型中，那么模型還是模型嗎？

這個manager，我介紹的很簡單，能夠領悟到這一層的同學，不用說應該也明白。

他特別重要

manager能夠很好的處理數據和業務，如果讓他處理更多的任務，那么他就會變得臃腫不堪，這不是我們想看到的。因此我們需要再一次進化，我領悟到另外一種編程思想，也是本篇文章的核心思想

系統是一個具有一定功能的，相互間具有有機聯系的，有多種要素或構成部分組成的一個整體

系統是一個整體，他讓我撥開迷霧，大家仔細想想，其實控制器本身就是一個系統，蘋果把他叫做controller也不是沒有原因的。在控制器這個系統中，他內部所有的組成部分都是有機聯系的，既相互獨立又相互聯系，他們共同的目的就是完成該控制器界面的顯示任務。這就是最典型的一個系統

之前，我經常把控制器想象成一臺機器，view是該機器上的零件，view的manager是該零件的管理者，基于這樣的思想，寫出的代碼中，view的地位大于manager的地位，manager為view服務。現在看來，這種思想是有局限性的。

控制器是一個系統，能夠完成一定功能的view和manager他們應該也是一個系統，他們的關系既相互獨立又緊密相連。

系統是有輸入和輸出的，寫輸入和輸出，是我最近編程中要研究的地方。

到此為止，代碼的復用其實就是系統的復用，事件和數據的操作就是系統的輸入輸出。一個控制器可以添加多個子系統，子系統根據輸入配置view，然后添加到控制器的view上，大致是這樣一個過程。

兩個以上的元素組成才叫系統，一個元素我們使用manager的思想。因此，一個tableview完全可以是一個系統的輸出，一個cell完全可以使用單一功能的manager進行關系，把事件拋給響應的系統進行處理。

這篇文章用時1小時20分，一氣呵成，蛋疼的是沒有任何代碼示例，也算是我自己編程思想進化的一個里程碑吧。果斷時間我用這個系統的思想寫點例子之后再重新發文。