今天與人再次聊到這個話題,有人在為"到底該用什麼模式"而煩惱,我相信,每個都經歷過這個階段一定都會感覺很熟悉這個煩惱
我認為, 模式不是目的,只是工具,達到設計目標的工具,我們不會因為"為了使用錘子"而去"使用錘子",一定是因為其他目的"比如敲打釘子"而去"使用錘子".
我們應該也同樣不要因為"想用那個模式"而去"使用模式",而一定是因為其他的目的而去"使用模式",比如為了達到"單一職責"使用"工廠類模式"以達到"將構造職責和物件本身的職責"分離,為了達到"對修改關閉"而使用"訪問者模式"將"物件的行為"與"物件的表示"分離等等.
有人說在現代的語言裡(如.net,j**a),有的模式已經沒有用了,如觀察者,簡單工廠等,其實這僅僅只是因為這些語言裡對這些模式有了更好的支援，但是熟悉這些模式本身還是很有意義的，正如候先生所說：「勿在浮沙築高台」。
有人說「我個人認為，解決重複的問題不用設計模式，用物件導向的知識就能解決，用設計模式，我主要是解決變化的問題」，我認為：
ood和模式是無法比較的,抽象層次不一樣
ood的抽象層次高: 比如 水果
模式的抽象層次低: 比如 香蕉
你不能說: 水果和香蕉那個好吃一些
有人說「感覺有些模式就是因為以前語言和編譯器能力底下才產生的一些設計方案」，我認為正好相反，因為有的模式是如此精妙 ，所以現代很多語言將模式的很多機制整合進來。
也有人說「ioc一出來。很多模式就沒得用了」，我認為 ioc和模式不是乙個抽象層次上的，ioc是屬於ood原則裡的，相當於倒置倚賴，模式是ood的工具，語言是模式的工具，就想你不能說：有了水果，香蕉就沒用了。
模式是工具,不是目的
目的是那些基本原則:
比如高聚合,低耦合,ood原則等
終極目的其實只有乙個:不要重複(not repeat),這是最終目的
OOD 隔離變化 橋接模式
正如電腦主機和顯示器之間，主機的配置千變萬化，不斷公升級，顯示器可能公升級緩慢。如果這時你買的是一體機，硬體公升級就要受到限制。這就是乙個典型的分離變化的需求場景。在應用中,乙個業務會有多個協作者，直接耦合會導致其中乙個類的變化就會影響其它類的行為。這時最好的做法是對行為進行抽象，區分出變與不變，或...
設計模式 OOD的設計原則 1 開 閉原則
這些ood原則的乙個基石就是 開 閉原則 open closed principle ocp 這個原則最早是由bertrand meyer提出,英文的原文是 software entities should be open for extension,but closed for modificat...
設計模式 OOD的設計原則 2 黎克特制代換原則
那麼什麼是黎克特制代換原則呢?有個嚴格的表述,繞口,不好記.還是比較白話的這個好記.說的是 乙個軟體實體如果使用的是乙個基類的話,那麼一定適用於其子類,而且它察覺不出基類物件和子類物件的區別.也就是說,在軟體裡面,把基類都替換成它的子類,程式的行為沒有變化.lsp是繼承復用的基石,只有當衍生類可以替...