什麼時候在重構switch語句時選擇策略over多態性

Question

您可以給我特定的原因何時選擇stratigy而不是polymorphsim，反之亦然。

非常感謝！

Answer 1

一個重要的標準是多態性是否會產生策略會避免的耦合。例如，如果爲使用低級I/O函數的類樹實施「save（）」方法，那麼如果使用多態性，則類的樹將耦合到I/O系統，而不是「 t之前。但是，如果您使用策略模式，那麼策略對象將充當「緩衝區」並使類樹不依賴於I/O。

Answer 2

你用null開始你的應用程序。

下一步是多態的原始代碼。

基本情況下，它可以保持這種方式 - 這不是問題。

如果你希望你的應用程序更加靈活，爲變化做好準備，並且你打算繼續開發它 - 現在是時候去尋找一些設計模式了，當多態現象給出時，策略就是你應該考慮的巫師之一一些麻煩。

---

意向策略：

定義一系列的算法，封裝每一個，使得它們可以互換。策略可以讓算法獨立於使用它的客戶端。

---

動機使用策略：

許多算法打破文本流成存在lines.Hard佈線所有 這種算法到需要它們的類是不可取的幾個 原因：

·如果包含 換行代碼，需要換行的客戶會變得更加複雜。這使得客戶端變得越來越難以維護，特別是如果它們支持多種換行算法的話。

·不同的算法在不同的時間適用。如果我們不全部使用它們，我們不希望 支持多種換行算法。

·當線路中斷 是客戶端的一個組成部分時，很難添加新的算法和改變現有的算法。 我們可以通過定義封裝不同的 換行算法的類來避免這些問題。以這種方式封裝的算法被稱爲 策略。

---

後果：策略類的相關algorithms.Hierarchies的

1. 家庭定義 家庭的算法或行爲的上下文重用。繼承可以幫助將算法的常用功能分解出來。

2. Subclassing.Inheritance的替代方法提供了另一種支持多種算法或行爲的方法。您可以直接對Context類 進行子類化，以賦予它不同的行爲。但是這會將行爲 硬連接到Context中。它將算法實現與Context相混合，使上下文更難以理解，維護和擴展。並且您不能動態改變 算法。你會發現許多相關的類，它們只有它們所使用的算法或行爲不同。將 算法封裝在單獨的策略類中，可讓您獨立於其上下文來更改算法 ，從而更輕鬆地切換，理解和擴展 。

3. 策略消除條件語句。策略模式提供 條件語句的替代選擇所需的行爲。 當不同的行爲被集中到一個類中時，很難避免使用條件語句來選擇正確的行爲。在單獨的策略類中封裝 行爲將消除這些條件 語句。