當我們練就一身功夫，站在擂台上之後...
擂台上，我們可以想像一個學會各種搏擊技術，具有扎實的功夫底子的選手， 為何在上場之後，無法應付自如，在對方三兩下之後，慘敗退場。
我們會說，光學會所有搏擊技術，但缺乏臨場經驗，仍無法應變擂台上的變化萬千。
的確是的!回到程式設計本身來說，也呼應這樣的結果。在程式開發上，常發現這類的問題。當我們擁有程式語言的所有技巧(Skill)，但卻無法順利完成一套系統，或者讓系統可輕鬆維運。
在在說明，我們在學習與模擬的程式技巧之後，缺忽略解決方案與應用系統架構的重要性，或者我們根本在設計系統時，沒有這樣的思維與概念。
所以，深入學習設計模式(Design Pattern)，進而了解如.NET Framework 與 Java 等相關 Framework 實務上的整合應用(這些框架如何善用了設計模式建構密不可分，又可拆解開來使用的)。
如果，您在熟悉物件導向程式設計的基礎下，又能加上對設計模式的透徹了解，並且靈活應用。俾能讓您在設計應用系統或者使用各類型 Framework 過程中，快速與正確使用到這些框架的精隨。
在尚未上擂台之前...
師父說，我們需要更精確的臨場經驗，一堆「套式」一定要好好學。
《真正的目的，就是不要在擂台上被對方打倒。》
但是，程式設計師們當努力學習所有設計模式，往往就面對如圖一這樣的問題(以一個工廠設計模式為例)。
圖一 工廠設計模式描述方式
是的，我們面對的就是程式設計師的通病用語，從理論基礎架上程式軟體工程專業術語，在跟你說如何實作這樣的模式。並且搞出一個一般人無法了解的 UML Class Diagram。
這就是專業，這就是邏輯工具人的習性用詞與解釋方式。
接下來呢?我們絕對可以使用不同的程式語言加以實現。最後，我們在回到程式系統真正的需求上來思考，我又為何要使用這樣的設計模式?
講人話，說出你對自己撰寫的系統上線的痛點...
對於應用系統開發過程中，或者上線維運的真實狀況是：
當作業系統或者框架改版時，為何我的系統呈現快閃或者出現錯誤。
為何在使用 Framework 進行系統開發時，我總是無法將框架中的類型使用的非常精確，往往只是透過前人寫過的範例程式當作範本，加以模擬。
使用單位將應用系統的事物流程一個小修改，會議上一個小時定論，修改程式往往要一個星期才能完成。
為何老闆總是說改就改的程式流程，會變成程式設計師最大的痛，幾乎加班加不完。
應用系統往往在轉換版本時，為何如此困難，為何往往要再生工程計畫。
如圖一 工廠設計模式，設計的目的是為了解決那些問題?否則為何要將簡單直擊的程式碼撰寫，轉換成繁瑣的軟體工程與設計模式來進行?
圖二 講人話的軟體工程溝通目的
《工廠設計模式》真正的意義在於，讓應用系統在面對不可控制的軟體環境下，向前面與後面的版本相容;或者是自行控制的版更之後，不至於讓您的應用系統垮掉。
概念與邏輯的轉換過程中...
在說人話(概念溝通)下的，實際上會提列真正系統開發的目標，接下來在將程式設計專業的術語與技術架構套上，所以就會變成如圖三的說明一般，在跟圖二對照一番。這時候我們似乎可以更人性化的了解工廠設計模式的真正目的與意義。
圖三 使用邏輯與物件導向概念設計工廠設計模式
在開始學習設計模式之前，筆者建議您，嘗試將您面對的軟體開發真正的痛處釐清;或者讓您將來在維運系統時，因為不清楚的軟體工程架構，可能讓您走向如下面條列的的程式工程師真正工作內容的生涯狀態:
一年開發工程師->上線變成維運工程師->再過一年之後變成除錯員...
為了避免讓工作內容降階的窘境發生，因此建議好好思考軟體工程，寧願多三分鐘的思考，可避免開發系統走入一個死胡同。
程式設計師的必要裝備
1.設計模式下的軟體工程
Comments