最近在考項(xiàng)目管理的課程，學(xué)到了系統(tǒng)工程這一門課，有一些感觸和領(lǐng)悟，特在此記錄一下。
這些想法和下邊敘述的內(nèi)容都是我個(gè)人在編程方面的一些想法，由于不善寫作，可能例子會(huì)比較少。有興趣的朋友，可以在評(píng)論區(qū)留言，我們做進(jìn)一步的交流。
先說說我得出的結(jié)論：當(dāng)我們使用系統(tǒng)的思想去處理程序，有很多令我疑惑的問題就迎刃而解了，我會(huì)圍繞這個(gè)思想一步一步的解釋，為什么系統(tǒng)的思想能夠解決困惑我的問題。
記得我剛開始學(xué)iOS那會(huì)，我們寫的最多的代碼就是tableView，我們從最簡(jiǎn)單也最有問題的地方開始。我看到過很多初學(xué)者在寫cell的時(shí)候，直接在控制器中給cell添加各種各樣的控件，這會(huì)有很大的問題，當(dāng)別人想復(fù)用這個(gè)cell的時(shí)候該是多么的痛苦。
顯而易見，上邊說的就是最低級(jí)的方式，甚至連MVC的概念也沒用到，好了，接下來我們用一個(gè)模型來封裝cell。這應(yīng)該是當(dāng)下iOS編程中使用最多的方式，cell和模型有很強(qiáng)的耦合關(guān)系。這種情況下的cell，往往使用一個(gè)獨(dú)立的文件創(chuàng)建，在初始化方法中創(chuàng)建控件，在模型的setter方法中配置控制。這里的配置就包含了賦值操作和根據(jù)模型中的屬性控制顯示方式的操作。
這么做符合mvc的概念，控制器和view之間通過模型作為連接的管道，同時(shí)也減少了view復(fù)用的代價(jià)。但這樣仍然有很多問題，知道了問題的所在，我們的架構(gòu)才能夠進(jìn)化：
根據(jù)業(yè)務(wù)的復(fù)雜程度，我們?cè)谀Ｐ偷膕etter方法中，要處理的業(yè)務(wù)也會(huì)各不相同。原理上，界面如何顯示跟模型有極大的關(guān)系。雖然這種方式能夠正確顯示數(shù)據(jù)，但無法緩存frame。我會(huì)在后邊講到，為什么這種通過setter賦值的方式很不符合編程中的語(yǔ)義要求。
假如說cell中有一些控件是有點(diǎn)擊事件的，這些事件中需要發(fā)送網(wǎng)絡(luò)請(qǐng)求。有的人喜歡通過代理的方式把事件傳遞到控制器中，這么做的優(yōu)點(diǎn)是能夠得到控制器這個(gè)對(duì)象，因此就能夠輕易的使用控制器的屬性，比如說添加加載控件到控制器的view上，或者使用控制器中的某個(gè)參數(shù)，但往往有點(diǎn)擊事件，就有數(shù)據(jù)更新，
依賴于模型setter方法的弊端就顯現(xiàn)了出來，你必須要先修改模型后，再去刷新tableview，此時(shí)此刻，我們就稱之為這個(gè)模型被污染了。
一種好的設(shè)計(jì)方案是，界面的顯示有一套模型，數(shù)據(jù)源是另一套模型，這種方案，我們馬上就會(huì)講到。
我見過那種把事件的邏輯直接寫到view中的，這樣做省卻了代理傳值的麻煩，且view基本上能保持功能的完整性。當(dāng)我們?cè)趧e的地方復(fù)用該view的時(shí)候，不需要在控制器中寫重復(fù)的代碼。缺點(diǎn)是無法獲取控制器屬性，即使能夠獲取控制器，也只有再把控制器屬性暴露在.h中才能使用，這就破壞了編程中的封裝性。
如果你的代碼中很少使用類似于readonly這樣的權(quán)限屬性，那么你就應(yīng)該去學(xué)學(xué)這方面的知識(shí)，這不是一個(gè)屬性的事情，而是一種編程思想的問題。
說到這里，我們已經(jīng)明白，使用模型的setter這種方式開發(fā)是一種常見行為，但是弊端也很明顯，它并不能成為一個(gè)拿得出手的技巧。我們接下來說說view model這一概念，我們簡(jiǎn)稱為vm。vm可以算是model和view的一個(gè)中間過程，其實(shí)，編程的本質(zhì)還是處理數(shù)據(jù)。在vm中我們通過model可以配置出view所需要的任何屬性，因此view得到解放，它不必關(guān)系這一過程是怎樣的，只需要拿到vm中的屬性直接顯示就行。
同理，vm還緩存了view中各個(gè)控件的frame信息。有的人可能會(huì)把vm叫做frame模型，這是不合理的，提供frame只是一個(gè)小小的功能，提供view直接顯示的信息才是它的核心功能。
舉個(gè)簡(jiǎn)單的例子，有一個(gè)cell，上邊有3個(gè)label，我在使用vm的時(shí)候，根據(jù)模型計(jì)算出這3個(gè)label的attText，然后使用yylabel顯示數(shù)據(jù)，同時(shí)，在vm中計(jì)算label的frame，因此cell中的代碼就很干凈，簡(jiǎn)單。這時(shí)候，vm就接管了cell的顯示任務(wù)，模型作為核心數(shù)據(jù)，不會(huì)被污染。
vm仍然有它的問題，跟新數(shù)據(jù)算是一個(gè)問題，時(shí)間的傳遞它也并沒有很好的解決。
上邊的兩種設(shè)計(jì)雖然有問題，但仍然需要使用，后來，我冒出來一種manager的想法。manager擁有提供和處理數(shù)據(jù)的能力，它很想一個(gè)超強(qiáng)大腦，能夠?yàn)関iew或者控制器提供任何想要的數(shù)據(jù)和功能。
想想一下，一個(gè)表單，有很多項(xiàng)需要填寫，manger可以提供一份默認(rèn)值，可以保存編輯后的值，可以驗(yàn)證數(shù)據(jù)是否合法，可以獲取參數(shù)字典等等，它都可以做到，因?yàn)檫@些數(shù)據(jù)就在它內(nèi)部保存著，沒有誰比他更清楚這些東西。這在語(yǔ)義上是比較符合要求的，如果我們把這些復(fù)雜的需求保存在一個(gè)模型中，那么模型還是模型嗎？
這個(gè)manager，我介紹的很簡(jiǎn)單，能夠領(lǐng)悟到這一層的同學(xué)，不用說應(yīng)該也明白。
他特別重要
manager能夠很好的處理數(shù)據(jù)和業(yè)務(wù)，如果讓他處理更多的任務(wù)，那么他就會(huì)變得臃腫不堪，這不是我們想看到的。因此我們需要再一次進(jìn)化，我領(lǐng)悟到另外一種編程思想，也是本篇文章的核心思想
系統(tǒng)是一個(gè)具有一定功能的，相互間具有有機(jī)聯(lián)系的，有多種要素或構(gòu)成部分組成的一個(gè)整體
系統(tǒng)是一個(gè)整體，他讓我撥開迷霧，大家仔細(xì)想想，其實(shí)控制器本身就是一個(gè)系統(tǒng)，蘋果把他叫做controller也不是沒有原因的。在控制器這個(gè)系統(tǒng)中，他內(nèi)部所有的組成部分都是有機(jī)聯(lián)系的，既相互獨(dú)立又相互聯(lián)系，他們共同的目的就是完成該控制器界面的顯示任務(wù)。這就是最典型的一個(gè)系統(tǒng)
之前，我經(jīng)常把控制器想象成一臺(tái)機(jī)器，view是該機(jī)器上的零件，view的manager是該零件的管理者，基于這樣的思想，寫出的代碼中，view的地位大于manager的地位，manager為view服務(wù)?，F(xiàn)在看來，這種思想是有局限性的。
控制器是一個(gè)系統(tǒng)，能夠完成一定功能的view和manager他們應(yīng)該也是一個(gè)系統(tǒng)，他們的關(guān)系既相互獨(dú)立又緊密相連。
系統(tǒng)是有輸入和輸出的，寫輸入和輸出，是我最近編程中要研究的地方。
到此為止，代碼的復(fù)用其實(shí)就是系統(tǒng)的復(fù)用，事件和數(shù)據(jù)的操作就是系統(tǒng)的輸入輸出。一個(gè)控制器可以添加多個(gè)子系統(tǒng)，子系統(tǒng)根據(jù)輸入配置view，然后添加到控制器的view上，大致是這樣一個(gè)過程。
兩個(gè)以上的元素組成才叫系統(tǒng)，一個(gè)元素我們使用manager的思想。因此，一個(gè)tableview完全可以是一個(gè)系統(tǒng)的輸出，一個(gè)cell完全可以使用單一功能的manager進(jìn)行關(guān)系，把事件拋給響應(yīng)的系統(tǒng)進(jìn)行處理。
這篇文章用時(shí)1小時(shí)20分，一氣呵成，蛋疼的是沒有任何代碼示例，也算是我自己編程思想進(jìn)化的一個(gè)里程碑吧。果斷時(shí)間我用這個(gè)系統(tǒng)的思想寫點(diǎn)例子之后再重新發(fā)文。
