筆者我也是一個剛剛稍微瞭解物件導向是怎麼回事的人，很高興可以有機會寫一篇冗長而囉唆的文章跟你分享這個系列文章的第二集：
為什麼我找出來的物件都是UI物件？
P.S.: 本篇為邀稿之作，請真正的初學者現身說法。由於作者本身才剛經歷過初學之痛，記憶猶新，能更深刻的體悟出：初學者的該如何跨過那道看不見的門檻！
或許身為初學者的你，開始嘗試以『你所知道的物件導向』的精神，建構你的程式碼。初學者在開始起步的時候，會積極的想一個專案，嘗試自己開發。而我相信，在你初步規劃之後，開始寫碼，沒多久你就會不知所措。你會開始疑惑你自己的規劃是否正確的把物件導向的精神用上，然後，有可能寫了一部份程式碼之後，回頭修改介面，如果你的情況堪稱順利，你會繼續寫下去，或許你運氣好，或許你領悟力高，可以順利的開發完成。但是一般普通的初學者，會在這個階段裡，因反覆的修改介面，而使得寫碼的進度日漸緩慢，最後終至停擺。
如果你有這樣的問題，來，深呼吸一口氣，我們一起走出迷宮吧！
我們回想一下我剛提到的『在你初步規劃之後』的這件事情，身為初學者的我們是怎樣做初步規劃的呢？依據是什麼？
身為初學者的我，會很直覺的把自己想像中的『使用者』搬出來，在腦海裡操作這個系統，然後自己又同時扮演自認為是客觀的『第三者』，忠實紀錄『使用者』使用系統，與系統互動的各種行為，然後以這個觀點出發來規劃程式碼的結構。
好，不用講什麼複雜的理論，就可以輕易驗證這項錯誤。從直覺的角度來看，一個系統完成之後要賣給客戶，中間會一再的跟客戶溝通，溝通中正常的情況是客戶每次的面談中都會修正UI的部分。修改UI本身沒有問題，客戶都是如此，但是如果你發現你設計出來的架構，是每當操作介面改變，整個架構就要跟著大幅度修正的情況，那我想你應該是掉進這樣的陷阱裡了。
因為我們從『使用者』跟『程式運作』的地方開始思考，我們自然而然就把出發點放在UI了，於是乎我們在規劃的時候，會把焦點放在每個表單上有什麼按鈕，使用者可以做哪些控制，然後使用者控制之後，程式要做出哪些回應。既然你的出發點是使用者面對的每張表單，你規劃程式的時候，自然會把互動關係切割成『一張表單與另一張表單之間的互動』。
沒有例子你沒有感覺，講個最常見且最深刻的例子Visual Basic，以下簡稱VB。
做為一個剛接觸程式設計的入門工具，VB的強大可以讓初學者快速的體驗寫程式的成就感，視覺化的工具與直覺式的思考，讓初學者想不愛都難。不過這僅止於入門，如果你今天要學的是物件導向，一直以傳統VB的思維出發寫程式的人，就會吃了大虧。每個副程式都綁在表單上，如果一段程式碼要重複使用，很可能就是用拷貝的動作，再另一個表單也存一份。表單之間可以用按鈕跳來跳去，資料也沒保護好，不是沒辦法重複使用，就是不同表單互相亂用，這種寫法寫小型的專案、獨自一人開發時或許可以輕易掌握，但是試想，如果今天面對的是大型專案，同時多人分工開發的時候，會出現怎樣的情況？
有幾百種表單，互相資料用來用去沒有管控，可能引發資料一致性發生錯誤。功能相同可重複使用的程式碼，因為每個人的分工以表單計算，所以各自用不同的寫法寫在各自的表單裡，使用者操作流程一有修改，表單修改程式碼跟著改，卻無法清楚知道修改幅度到底是怎樣，除此之外還包含許多隱藏錯誤的可能性。
傳統VB並不是完全物件導向的語言，他只是一種可使用UI物件的程序式語言罷了。既然如此，VB是否不行做大型專案，答案是：『可以！』不僅如此，VB還可用物件導向精神的方法去規劃並且開發大型專案。
講了這麼多，只是要描述，使用UI規劃程式架構的陷阱及謬誤：
分析程式架構的時候，我們應該從『任務』的觀點出發，看待整個程式。
從任務觀點出發，我們還是可以從UI看起，這時候，我們看待UI的方式改變了。UI的任務是，負責把程式『暗地裡』做的事情，表達給使用者，並且把使用者的動作，呼叫產生對應的實體去工作。
發現不同點了嗎？原本的UI裡，把程式的運作綁在UI上，UI的物件除了負責面對使用者之外，自己本身也要負責把事情做完。於是乎UI變成一個執行動作的實體，每當UI一改，整個架構都會跟著改。可是現在UI的工作很輕鬆，他只要專注在互動上，跟互動無關的程式內部運作，就呼叫其他實體來做。
這樣一來，互動的UI怎麼改，都不會影響程式內部真正要完成的事情，而程式內部的運作，一旦有更好的演算法，就可以更新，也不會影響到UI。除此之外，你還會發現，從這樣的觀點切入，你比較不容易漏掉以往因為專注在UI上，而漏掉與UI無關卻還是需要完成的任務上，這些隱晦的任務在一開始規劃的時候就比較會考慮到，比較不會漏掉。一開始漏掉而之後才想到要補上去的『任務』，往往也是造成修改架構的因素之一。
所以，如果你發現規劃完畢之後，你的物件圍繞著UI打轉，你必須把焦點從UI拉回任務本體，重新檢視這個系統的每一個任務，並且把UI想成完成系統的其中一部份任務，UI必須要跟其他人溝通，然後列出所有要完成的任務的清單，並且把任務切成有限單位的子任務。並且把要完成該任務的資料、方法，做好包裝，不要讓不相干的任務跟資料混雜在一起，如此一來，就可以產生基本的物件雛形，就算未來有修改的可能，也因為你在此時已經先做好分類跟分割，未來影響的幅度得以縮到最小，得以控制。
更多「物件導向」文章：
繼承是父子關係？才怪！ 物件導向初學者應該要知道的事情(四)
更多「程式設計」文章：
留言列表
