2009-05-23 78 views

回答

19

我建議反轉控制/依賴注入。這在單元測試時非常方便,因爲它使您能夠爲受測試的類提供模擬依賴關係。包裝密封類以使其在測試場景中更易於使用時,代理也非常有用。

如果我提出另一個建議,我會專注於學習哪些模式在不同情況下有用,而不是專注於學習如何實現特定模式。在實現模式時,幾乎總是可以找到一個參考實現,但能夠辨別何時使用哪種模式將使模式更有用。如果你以另一種方式開始討論它,那麼最終會讓你的問題適合你所知道的模式,而不是採用適合問題的正確模式。

+2

加上:「我會專注於學習哪種模式在不同情況下有用,而不是專注於學習如何實現特定模式。」設計模式最大的問題在於傻子們不恰當地使用它們,因爲他們讀了這本書,並認爲這本書說這是「正確的」,但事實上它沒有這樣的東西...... GOF明確地說是「一盒工具」。這不是一個前提性的元配方。 – corlettk 2009-05-23 04:41:45

+1

+1您的答案的第二段。將設計模式視爲描述常見問題的常見解決方案的詞彙表非常有用。詢問首先要學習的設計模式,就像詢問爲了成爲醫生首先應該記住哪些醫學詞彙。 – 2009-05-23 04:53:06

0

Singleton在許多地方使用非常嚴重。 Adapter模式也很常用。這兩個是最常用的,並且相對簡單;瞭解它們可以有助於理解模式,並且可以對您的開發有用。

+2

單身人士基本上已被棄用,主要是因爲任何單身人士不能在沒有單身人士的情況下進行測試。例如:除了那個dang DB.conn()方法以外,你可以用一個數據庫測試一個DAO。但是,是的,你會在現有的代碼中看到很多,而且它仍然很常用。 ConnectionFactory.getInstance()每次都可以返回相同的連接,而不會將您鎖定爲implimentation。 – corlettk 2009-05-23 04:36:39

4

我認爲設計模式的用處更多地在於它們附帶的附加詞彙表,而不僅僅是使用單個(或幾個)模式。在嘗試與其他開發人員溝通時,掌握四人幫的常用模式的工作知識是非常有用的。

我建議閱讀目錄,然後閱讀模式目錄的摘要。如果你對時間有限,大致瞭解這些模式的符號是有益的,這樣當你需要知道模式的細節時,你就會知道在哪裏尋找。這與在自己的小島上了解州或單一族的模式不同。

2

抽象工廠。用於依賴注入(DI)。
如果你明白,你知道DI基本上是如何工作的,然後你就知道控制反轉是什麼。

6

設計模式不是您快速開始閱讀和學習的主題。 你將不得不做很多練習,然後運用你在真實場景中學到的東西。 如果你的時間真的很有限,那麼你可能會浪費你的時間。 我建議書Head First Design Patterns,這是很好的。

但是你的面向對象的知識應該在相當高的標準下開始。

+0

+1偉大的書開始學習設計模式與 – 2009-05-23 05:14:25

1

「命令」模式比抽象工廠稍微複雜一些,但常用,功能強大。

另一種我從未真正有機會使用的模式是「複合」模式。這個會給你很好的面向對象技術,並且如果你遇到它,它可能會證明是有用的。

6

你的問題就像問:「我想學習C#,但只有時間學習一些關鍵字,我應該學習哪些?「

任何一種設計模式都沒有生活在真空中它們都定義了應用程序如何結合在一起的不同方面任何一個應用程序都不可能需要所有已知的設計模式,但每個應用程序都是不同的,每個應用需要不同的組合,知道什麼不使用與知道使用什麼一樣重要,至少需要所有主要設計模式的會話知識。 Head First Design Patterns這本書之前提到過,學習一點關於它們的全部內容,不要因爲沒有時間而花時間 - 花時間!不要在FaceBook上多呆兩晚,或者跳過一兩次Star Trek重新跑步。

另外,首先要避免the GoF patterns book,除非你真的是面向對象的大師。它非常密集,立即讓你瞭解模式的價值和需求。這是一本很棒的書,不是一本很棒的第一本書。

1

我認爲'飛錘'是一個非常酷的模式,它與其他任何東西都沒有任何關係。 (即,你永遠不會決定使用另一種模式)

但是,如果你只學習一種模式,'訪客'就是你想要的模式。這是一個遠遠超出OO編程的概念;它將幫助您瞭解功能編程概念,如mapfold。甚至可以使用OO方法,例如collectinject

1

策略是我的名單上。這是刪除條件邏輯代碼的好方法,它只是爲了支持多種處理方式,它有助於提取「策略」代碼,以便可以對其進行單獨測試。

1

GoF的(四人幫)一書建議將這些作爲開始:(在「指南讀者」的書)

從最簡單和最 常見的模式:

  1. 抽象工廠
  2. 適配器
  3. 複合
  4. 裝飾
  5. 工廠方法
  6. 觀察
  7. 戰略
  8. 模板方法
1

我一直親身感受到,你不「學」的設計模式......你要學會「認」他們。換句話說,當我第一次閱讀設計模式時,他們中的很多人似乎都是在我之前創建的應用程序中自然而然地出現的解決方案,但也許我並沒有完全一樣地或完全地做到這一點。

在我看來,設計模式更多的是關於標準化一遍又一遍的解決方案,而不是教你如何解決一個特定的問題。