面向變化編程

面向變化編程

吳旻

泰岩網路工作室

 

         現在的程式員，大多使用物件導向開發工具，寫面向過程的代碼，來完成面向變化的任務。

         物件導向編程現在不僅深入到軟體開發領域，而且已經到了強迫性的程度了。比如像JAVA和C#語言，為了想完成一個函數，你幾乎也得寫一個類，也就是說，它寧願失去靈活性，也不願意讓你用面向過程的方法來進行編程。

         用心良苦呀！要知道，設計程式設計語言的都是大師級的人物，他們做出如此決斷，一定是有其原因的。

         首先是面向過程是本能性反應。寫面向過程的代碼，幾乎不需要太多練習就能寫出來；而寫物件導向的代碼，就得經過長時間的練習，尤其是資料抽象方面的訓練。因此大師們乾脆就讓你從一開始就進行這方面的訓練，免得日後生事。

         其次是面向過程只能解決相對簡單的開發工作單位。無數經驗證明，要想開發大型、多模組、多協作的項目，物件導向語言確實是最好的。

         還有一點是最重要的，物件導向語言編寫的代碼，相對來說，可複用性高。這就像人類知識的積累過程一樣，今天問題的解決方案，明天遇到相同的問題，拿來就用了，多方便呀！

 

         那為什麼還會有那麼多程式員用物件導向語言，寫面向過程的代碼呢？其實就是人的本能是就問題解決問題，多思考一步，多想一想將來，那個是需要訓練才行的。比如，物件導向的核心思想其實是進行資料抽象，只有進行抽象，你才能把一個又一個的問題，抽象成一類問題，從而找到統一的解決方案。

         說實話，我發現很多程式員，其實天生就不適合做物件導向編程。要麼反應速度非常快，以至於有些衝動，上來就改；要麼反應速度太慢，或者說太聽話了，你說什麼他就做什麼，你沒說的，他就堅決不做！

         物件導向編程是一種修養或者修鍊，需要像玩遊戲那樣一級一級的過關。

 

         然而不幸的是，會物件導向編程，現在已經遠遠不夠了。開發經驗證明，軟體需求往往是處於不斷變化當中的；它不像建築設計那樣，一旦定好了，就很少調整，而是像戰役部署一樣，隨時會根據戰役進展情況進行調整。

         那麼如何用物件導向語言寫面向變化的代碼呢？我們都知道物件導向中有一個概念叫封裝，封裝什嗎？讀書的時候，學到的是封裝資料類型，封裝不想讓外界知道的函數等等。其實我覺得不是！

         物件導向封裝的應該是變化！

 

         物件導向編程必須考慮變化，只有這樣，才是我們今天提到的面向變化編程。我們在編程中，必須有個預案，如果變了，我們的程式該怎麼辦？如果加入了新功能，程式該怎麼辦？如果出現架構調整，程式該怎麼辦？

         如果你將變化封裝到你的代碼中了，那這一切就都好辦多了。UML和迭代編程其實更多的是在管理上來適應需求變化，但如何在代碼上適應需求變化，其實就是另一回事了。

 

         業務建模要有針對性，要有自身的特點。

         我見到很多架構師用中關村攢電腦的本事來設計架構。比如，張三的主板，李四的CPU，王五的記憶體，趙六的硬碟，如此等等。好像這樣一堆，電腦就出來了。可是如果出問題的怎麼辦，比如記憶體和主板有點不相容而導致偶爾藍屏，誰來解決？或者使用者覺得記憶體不夠，結果發現內在槽已經用滿了，如何辦理？

         面向變化編程就是要提前預料到可能會發生的問題，並提前給出相關的預案。許多時候，其實僅僅是靜靜地坐下來，認真思考五分鐘的事。