使用設計模式(Design Pattern)的時機

先知先覺：覺得某個設計模式適用於目前的系統!
(憑什麼說適用?要有證據!)

後知後覺：重構!調整目前的架構，並把某個設計模式加入，讓系統更有彈性!
(為何重構的理由?)

照開發流程而言：需求、分析、設計、實作、測試、發行。
而設計模式的時機就在 設計、實作 這個時期。
為什麼這麼說?
功能都沒討論到一個程度，任何的實作都只會是實驗(有沒有做得出來的可能性)。 所以功能要先出來一個雛型!

如果時程很趕，當然是以軟體功能為優先!先做出來，看效果!
這時候若是一直想要讓系統更有彈性點!~有彈性點，相對的就會是增加架構的複雜度，反而會造成OverEngineering!加了一堆目前沒有用到的!

若是功能差不多出來了，而且這個系統還有很長遠的版本!也就是有很多的想法可以加入時，那這個時機點再來調整"系統結構"，"重構"系統的軟體架構，那設計模式的彈性，也許就是一個很不錯的考量!

分隔-----------

在深入淺入出設計模式一書裡，第十三章：與設計模式相處。其中一小段。

當你在設計時，儘可能地用簡單的方式解決問題，你的目標應該是達到簡單性，而不是「如何在這個問題中採用模式」。千萬不要認為：如果沒用模式解決某個問題，就不是專家。如果你能夠保持簡單的設計，其他的開發者將會相當尊敬。正確的說法是，為了讓你的設計簡單且有彈性。有時候需要使用模式。
……………
何時使用模式?當你在設計的時候，如果確定在設計中可以利用某個模式解決某個問題，那就使用這個模式!如果有更簡單的解決方案，那在使用模式之前應先考慮這個方案。
……
一旦找到了一個適合的模式，要先確定這個模式帶來的後果，以及對系統的影響是你所能夠忍受的。
………
加入模式是要因應實際的改變，而不是假定(可能)的改變。 (可能OverEngineering)
……

分隔-----------

彈性和簡單，我會直覺於簡單，愈簡單，就愈好理解!
至於要不要用設計模式，看情況吧!硬是要套用，反而會出問題!

在物件導向中 模組品質的定義

模組設計的準則：
在模組內有最多的關係
在兩模組間有最小的關係

如果產品是以模組來劃分，那如何知道模組的品質?
在物件導向中，有兩個名詞用來看待模組的品質，分別為：
Cohesion (strength)：模組內程式碼間的結合度。
Coupling (binding)：模組間的關連度。

Degree of Cohesion

Functional cohesion	(Good)
Informationial cohesion
Communicational cohesion
Procedural cohesion
Temporal cohesion
Logical cohesion
Coincidental cohesion	(Bad)

Degree of Coupling

Data coupling	(Good)
Stamp coupling
Control coupling
Common coupling
Content coupling	(Bad)

這兩個概念在教科書中常常出現；
這兩個指標很重要。為什麼重要?

因為都是用來看系統架構內的結構好不好，彈性夠不夠，相依性會不會過高。
而『重構』的概念 和『設計模式』的各種模式 皆是建立在這樣的基礎上。

依我個人的解讀如下：
在模組內，要求功能是不是夠集中。
在兩個模組之間，要求各自的獨立，不要有相依性。

論文程式 Demo

2008/07 完成系統一半的功能，但後續追蹤、重複通報欲鎖的疾病仍是不對
2008/08 重新繪製系統流程、功能
2008/09 重提系統畫面、流程、功能
2008/10- 2009/02/10 建構系統程式

歷時四個月多，終於完成系統主流程 的程式，其過程感觸良多。

打從研二確定論文題目後，一直很茫然不知所措，不知道要怎麼建構系統功能。
報告提案時，也一直被老師唸"你又在當醫生了!"，提出的報告也一直被推翻，書讀的很鬱卒，看著身旁的同學一個一個畢業，心裡的感受可想而知。

一直告訴自己，讀書有方法，那麼報告也是有方法的。
首先一定要讓自己提出的系統功能、流程過關。

直到研三，才驚覺不管是報告的能力、寫報告的能力、邏輯思考的能力(常常打結!)，都非常的弱。

既然有待加強，就開始找一些有關邏輯思考的書來看，如：
"邏輯思考技巧：寫作、簡報、解決問題的有效方法 "、
"你想通了嗎"、
"金字塔原理：思考、寫作、解決問題的邏輯方法"。

這幾本書，都非常值得一看再看，尤其是"邏輯思考技巧：寫作、簡報、解決問題的有效方法 "，所提的方法，檢示自己的報告的內容：是否重複、遺漏、離題，反問自己Why so?、So what?

而系統的功能、流程，一定是沒把握重點，所以老師才一直沒接受提案。
網路上有很多討論建構系統功能的高手，如矇矇的秘密基地、UML Blog。

尤其是矇矇的秘密基地中的幾篇文章。如：以架構為中心的主要設計產出(1) 、
以架構為中心的主要設計產出(2) ，提出了建構了系統的方法、先後順序、先後重要性、要畫那些圖才能凸顯焦點；真的是令我開了眼界，要說服別人的證據，原來是這麼建出來的。

在此萬分的感謝這些書的作者及 部落格的高手，不藏私的把自己的經驗分享在網路上。

沒有這幾本書和部落格文章的啟蒙，也沒辦法用好的思維模式，建構出可以說服老師的系統流程、系統功能。沒有某某科技公司的專案經理Magic蔡大哥及另一位孫大哥的指教，我也沒辦法那麼快知道系統實作環境中，目前的情境流程。當然還有老師的指導，沒有他指出正確的方向和系統流程，功能一定仍在修正中。

回到主題 程式Demo，要Demo前一定要做測試，做愈多的測試，系統就愈穩定。

原想說這次的Demo，只是讓老師看看目前的流程、做法、畫面，是不是還有修改、增加的空間 (明明都讀到研四了，還想這麼多!)，所以只做了系統流程中，較大功能的測試。

怎麼列出測試情境呢? 這問題在腦海中盤旋了好久，因為流程很大，又有好幾個角色，最後決定用系統流程的情境來測試，在不同的分支作出系統功能的效果。分支愈多，相對的情境就愈多，就愈讓人覺得難以抉擇怎麼列出重要的情境。

當Demo完成主功能後，還想demo非功能的情境，像似 修正公式，系統需重新載入公式，並重新計算，這部份老師就說：「恩!demo到這邊就好了，我相信那部份有做出來!」（很驚訝！因為心裡還想著說：是不是還有很多地方要修! 總覺得還有很多地方有錯!）

Demo就這麼完成了!!

應該還是有很多隱藏的bug!~趁口試前，趕快修一修!
不要口試的時候再出包，這樣會丟老師的臉。

雖然這只是個論文程式，並沒有真的要實際上線，但仍是想把它做好一點!
畢竟這是人生中的第一個從無到有的專案!仍有很多地方需要修正。
如：server對databae的錯誤流程機制、client 與 server之間溝通錯誤流程機制、畫面流程的流暢度。

接下來就剩論文書面撰寫和系統部份功能的修正、還有口試。

相依倒轉原則

程式者的胡言亂語 的文章 類別物件的產生（4）相依倒轉原則。

在wikipedia 中的解釋

在 wikipedia 的作法

在 良葛格學習筆記 的作法解釋

這是個很實用的作法，用在重構或是設計中，都可以解決物件相依的問題，改善架構的擴充彈性。

有空得多想想例子，這樣才能記得更清楚。

真正的問題

人生中重要的是，關注那些真正的問題（real problem），不要陷入那些細枝末節的問題（trivial problem）。就像蘇格拉底說的，「認識你自己」。