你不能沒有哪種GoF模式？

Question

如果將來您只能使用“ 四人幫”一書中定義的單一規范模式，您會選擇哪一個以及出於什么原因？

Answer 1

不是一種設計模式，但對我而言，這個原則絕對是我整本書編程風格中最具影響力的：

在類繼承上支持對象組合。

結合其他原則“程序到接口，而不是實現”，大多數設計模式自然而然地遵循。

在我看來，選擇一種最重要的模式是不可能的。 他們都有自己的目的，相得益彰。 就像詢問錘子或螺絲刀是否更有用一樣。 這取決於問題，有時你有一個釘子，有時你的螺絲。

Answer 2

抽象工廠模式或模板方法模式......但主要是抽象工廠模式。 它們在很多情況下都非常有用。

我特別喜歡抽象工廠允許您通過以不同方式遵循相同規則來准備您將來可能會改變您的程序的情況。

大多數情況下，抽象類允許您在代碼“內部”定義規范，限制代碼遵循該規范，而工廠允許您在這些規范中“選擇”。 簡單的美麗。

Answer 3

觀察者模式

Answer 4

我喜歡國家模式。 對於建模，好吧，狀態都有好處。 對於我正在編寫的游戲項目，我使用狀態層次結構來跟蹤游戲狀態。 它很簡單但非常靈活。

Answer 5

我會說裝飾者模式 。 主要是因為它已經在框架中大量使用。

例如，如果您編寫過這樣的代碼：

FileStream file = new FileStream("file.txt");
GZipStream compression = new GZipStream(file);
TextReader reader = new TextReader(compression);
reader.ReadAll();

然后你使用了Decorator模式。

Answer 6

如果我必須選擇一個，我會選擇封面上的MCEscher圖片，放在牆上。 ;）

Answer 7

這是一個棘手的問題，因為我發現當我學習模式時，我正在以非常類似的方式為許多設計模式實現許多系統（特別是更基本的模式，如創建模式或狀態，和戰略和模板）。

現在我知道了GoF，我無法在腦海中分離出我自然不會發現的模式，對我而言，這就是形成良好模式的模式。 一個好的模式很自然，你可以使用模式編寫代碼，因為它是一個很好的解決方案。

模式只是讓我們談談我們用普通方言編寫解決方案的策略。 我知道我沒有回答你的問題所以我applogize。

Answer 8

我喜歡訪客模式。 不止一次，我遇到了設計問題並無法解決問題，直到我終於發現訪客模式才是答案。

您可以向類添加任何功能，而無需更改它！ 只需在其中放入一個accept（）函數。

Answer 9

監聽器或觀察者模式。

無法想象我的生活中會檢查是否發生了事情。

其他：

1. 適配器 （如果您不想觸摸有效的代碼但是您沒有時間了解如何，或者您只是不知道），這非常有用
2. 州
3. 戰略

Answer 10

我不得不說Singleton模式。 你需要多少次一次又一次地使用一個類的實例！ 它可能被認為是反模式，但它是我經常使用的模式。

抽象工廠模式也是我一直使用的模式 ，並且當我們需要實現一組新的需求時，前期開發為我節省了數小時的重新分解。

Answer 11

行為模式 ：

• 陳述我的業務邏輯分配時的狀態;
• 上下文改變算法時的策略 ;
• 讀取對象集合時的迭代器 ;

Answer 12

我不能沒有的是迭代者。 我每天都用它。 我很難想象沒有它的生活:-)我最常用的是Decorator / Wrapper。