13
以下代碼示例是戰略模式copied from Wikipedia的實施。我充分的問題如下它...此Java策略模式是否具有冗餘上下文類？
wiki的main方法：
//StrategyExample test application
class StrategyExample {
public static void main(String[] args) {
Context context;
// Three contexts following different strategies
context = new Context(new ConcreteStrategyAdd());
int resultA = context.executeStrategy(3,4);
context = new Context(new ConcreteStrategySubtract());
int resultB = context.executeStrategy(3,4);
context = new Context(new ConcreteStrategyMultiply());
int resultC = context.executeStrategy(3,4);
}
}
圖案片：
// The classes that implement a concrete strategy should implement this
// The context class uses this to call the concrete strategy
interface Strategy {
int execute(int a, int b);
}
// Implements the algorithm using the strategy interface
class ConcreteStrategyAdd implements Strategy {
public int execute(int a, int b) {
System.out.println("Called ConcreteStrategyA's execute()");
return a + b; // Do an addition with a and b
}
}
class ConcreteStrategySubtract implements Strategy {
public int execute(int a, int b) {
System.out.println("Called ConcreteStrategyB's execute()");
return a - b; // Do a subtraction with a and b
}
}
class ConcreteStrategyMultiply implements Strategy {
public int execute(int a, int b) {
System.out.println("Called ConcreteStrategyC's execute()");
return a * b; // Do a multiplication with a and b
}
}
// Configured with a ConcreteStrategy object and maintains a reference to a Strategy object
class Context {
private Strategy strategy;
// Constructor
public Context(Strategy strategy) {
this.strategy = strategy;
}
public int executeStrategy(int a, int b) {
return strategy.execute(a, b);
}
}
考慮特別是上面的例子，是Context級冗餘？
例如，我可以通過使用現有的類和接口除了上下文想出以下復main執行和它的工作完全一樣。它仍然鬆散耦合。
（（編輯：在這個簡單的情況下，當我離開了Context類，會向我作出未來的錯誤））
public static void main(String[] args) {
IStrategy strategy;
// Three strategies
strategy = new ConcreteStrategyAdd();
int resultA = strategy.executeStrategy(3,4);
strategy = new ConcreteStrategySubtract();
int resultB = strategy.executeStrategy(3,4);
strategy = new ConcreteStrategyMultiply();
int resultC = strategy.executeStrategy(3,4);
}
摘要更新
以點形式列出通過回答和評論發現的內容：
- 上下文允許改變合成策略的使用方式（例如，它的調用時間）。在調用給定策略之前和之後，不同的上下文可能會做不同的內部工作。
- 上下文是高級別的「黑匣子」。上下文邏輯可以改變，也可以改變合成的策略（或使用不同的策略）而不會破壞客戶端，因爲客戶端只理解如何調用上下文。儘管我通過忽略上下文創建了維基百科樣例代碼的替代實現，儘管它與原始代碼一樣工作，但整個情況被簡化了（在這兩種情況下），而我的更改實際上意味着：1.它是不再是戰略模式，2.我錯過了這裏提到的戰略模式精神的好處。
- 我的替代實現使用了像Context這樣的主要方法，所以如果有效地模擬它，我還可以保留Context。通過創建一個不純的策略模式，就產生了混淆。我不需要重新發明輪子或嘗試變得更聰明（在這種情況下）。
如果任何其他問題有用，或者需要更正請留下評論，我會相應修改列表。
這是一個非常詳細的解釋，清楚地概括了上下文的重要性，包括支持代碼示例。大。 – 2010-01-06 03:34:10
我想還有一個Context類可以被子類化爲將行爲附加到基本上下文工作（即在執行其額外工作之前首先回調基本上下文處理）。任何具體戰略都可以做到這一點。這將允許各部分彼此獨立地改變行爲，但仍然可以通過基本類型來兼容。所以我開始意識到，通過替代實現在水平方向上存在很大的靈活性，並且通過繼承來垂直方式，以及這些方式的組合。有趣。如果沒有經過深思熟慮，情況也會變得很複雜。 – 2010-01-06 04:11:29
嗯。我不確定我喜歡多態「Context」的想法。國際海事組織，最好將不同的部分組合成一個連貫的「上下文」，然後針對每個適用的策略制定適當的策略。 – 2010-01-06 04:22:23