使用設計模式(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)

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

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

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

相依倒轉原則

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

在wikipedia 中的解釋

在 wikipedia 的作法

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

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

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