委託與OOP的C＃策略設計模式

Question

我想知道在實施策略設計模式時使用委託與OOP有什麼優點/缺點？

您推薦使用哪一個？或者委託人解決什麼樣的問題？如果OOP更好，我們爲什麼還要使用OOP？

謝謝！

-step

Answer 1

這兩種技術都可以是強大而有價值的 - 下面是關於何時使用哪些技術的一些看法。

使用一個接口/實施方法時的策略：

維護狀態

需要配置

使用依賴性注入需要

由一個IoC被配置容器（想想ConnectionProvider）

結合了多重責任（想想ADO的DataAdapter。NET）

太複雜或只要還有一個方法

很可能是子類來創建新的策略

需要將狀態信息返回給調用者

需要訪問的適用對象的內部

需要太多直接的參數

否則，傾向於使用基於Func鍵<>或行動<>的代表，特別是如果

1. 有可能是一個非常大的各種策略（想排序表達式）
2. 的戰略是最好的表現爲爲lambda
3. 有你想利用

Answer 2

我喜歡用一個接口來抽象我的策略。然後我的具體實現爲每個策略都有一個可見文件。當使用類而不是方法時，它會給你更多的靈活性。我可以使用Rhino mock來模擬策略來測試它。我也可以很容易地使用Ninject等DI框架來很容易地綁定策略應用。我使用委託來提取主要在WinForm對話框中的實現。

Answer 3

在現有的方法代表們的青睞：

• 使用lambda表達式和動態方法輕鬆實現代表輕鬆實現代表
個
• 代表可以從「正常」的方法來創建與正確的簽名
• 代表是多投可以是多次使用（雖然相對較少之外三項賽）

贊成的接口：

• 一個對象可以實現一個接口，並且還做其他事情：一個代表是只是委託
• 的interfac e可以有多種方法;委託只是有一個

可能會有兩種結果：

• 隨着你結束了兩個人的名字接口：接口和方法。與代表你只有一個。我常常發現，單方法接口重複上述相同的名稱兩次（變化）或方法的名字很平淡

我個人是代表們的靈活性的忠實粉絲，但它真的取決於情況。

Answer 4

在我看來，如果你使用代表，那麼你實際上並沒有實現Strategy pattern。你實際上正在實施更類似於Observer pattern的東西。設計模式的重點在於，當你說「我在這裏使用了戰略模式」時，每個人都對你所做的事情有很多背景。當你開始說「我已經使用了戰略模式，除了我自己的個人修改」，那麼事情就會變得渺茫。

但是，如果我明白你在說什麼，那麼關於策略模式的好處之一就是代表不太清楚，你可以有一個實現策略的對象層次結構。

假設我正在測試一些軟件。我想用鼠標和鍵盤進行測試。因此，我將實施策略模式以插入用於每個測試用例的接口方法...因此，我可以編寫一次測試用例，並使用MouseStrategy和KeyboardStrategy完全運行測試用例。從那裏我可以實現專門化，如MouseExceptForDialogsStrategy，MouseStrategy的專業化。任何熟悉OOP概念的人都可以很容易地理解這種層次結構，如何擴展它並覆蓋它，而如何實現和擴展與代表相同的結構則更爲複雜和更加晦澀。

與許多事情一樣......它不是「你能做到嗎？」的問題，而是「你應該做到嗎？」。