不知是我講的太好，還是大家天賦異稟，竟然都對我講的地方沒有疑惑。有些時候我都不知道，我在講什麼，大家好像都能了解，真是太神奇了。真是心有靈犀一點通啊！
我第一次看這個模式時，並不甚了解，在我多看了幾個多型的應用，以及多個模式設計後，才逐漸領悟到這個模式他所表達的意含。大家真是天縱奇才啊！第一次聽完就懂了。
我覺得模式的意義，是在於他提供了一個叫由彈性、再用性高的設計方法，當沒有特殊限制時，設計模式通常是最佳的抉擇。當然一個簡單的程式，通常並不會需要用到設計模式。但我們寫的系統，應該不簡單吧，當我們在設計架構時，就可以輕鬆的把模式的方法帶入進去，因為他通常提供較佳的架構與實作策略，當然我們也應該了解每個模式他的優缺點，在考慮現實狀況作適當的修改。我覺得設計模式通常是OO設計守則的實作，當遇到問題時從OO設計守則下手，再慢慢推演要使用哪個模式來實作，甚至依據現實狀況與設計守則來改造模式，達到無招勝有招的境界。
關於IMMain的實作策略模式的案例，我大概了解蘇哥提到可能的困難點，當某些動作無法外包時，該如何作。嘿嘿我好像想到解法了，有空來作看看，做出來再分享給大家看看。
PS.這次類別架構圖都是由visual 2005畫出來的，而且畫完就產生程式碼，的確是個好物啊！大家寫的時候可以試看看，寫這個範例，所花的時間比想像中的少。
我第一次看這個模式時，並不甚了解，在我多看了幾個多型的應用，以及多個模式設計後，才逐漸領悟到這個模式他所表達的意含。大家真是天縱奇才啊！第一次聽完就懂了。
我覺得模式的意義，是在於他提供了一個叫由彈性、再用性高的設計方法，當沒有特殊限制時，設計模式通常是最佳的抉擇。當然一個簡單的程式，通常並不會需要用到設計模式。但我們寫的系統，應該不簡單吧，當我們在設計架構時，就可以輕鬆的把模式的方法帶入進去，因為他通常提供較佳的架構與實作策略，當然我們也應該了解每個模式他的優缺點，在考慮現實狀況作適當的修改。我覺得設計模式通常是OO設計守則的實作，當遇到問題時從OO設計守則下手，再慢慢推演要使用哪個模式來實作，甚至依據現實狀況與設計守則來改造模式，達到無招勝有招的境界。
關於IMMain的實作策略模式的案例，我大概了解蘇哥提到可能的困難點，當某些動作無法外包時，該如何作。嘿嘿我好像想到解法了，有空來作看看，做出來再分享給大家看看。
PS.這次類別架構圖都是由visual 2005畫出來的，而且畫完就產生程式碼，的確是個好物啊！大家寫的時候可以試看看，寫這個範例，所花的時間比想像中的少。