strategy模式是對演算法的封裝。即使是乙個計算行為，如果其實現有其多樣性，為達到易擴充套件的目的，我們也有必要將其抽象出來，以介面的形式來定義。由於充分利用了面向 物件的多型性，在呼叫該行為時，其具體的實現是在執行期決定的。以稅收計算為例，假定稅收策略分為個人所得稅，和企業所得稅。根據策略模式，將稅收策略抽象為介面itaxstrategy：
public
inte***ce
itaxstrategy
各種稅收策略均實現該類：
public
class
peronaltaxstrategy
:itaxstrategy
}public
class
enterprisetaxstrategy
:itaxstrategy}
如果此時有乙個公共的類，提供稅收的相關操作，其中就包括計算所得稅的方法：
public
class
taxop
public
double
gettax(double
income)}
客戶端呼叫：
public
class",
op.gettax(1000));}}
這是一種典型的物件導向的設計思路。然而，對於一些簡單的演算法行為，我們也可以利用delegate委託的方式，來實現以上的設計，它雖然更近似於面向過程的設計，但其擴充套件性同樣靈活。如果演算法的邏輯不複雜，且演算法的實現處於某種待定的狀態，也許使用委託會比strategy模式更方便。
我們同樣利用上述的例子，只是將原來抽象出來的介面修改為委託：
public
delegate
double
calculatetax(double
income);
對於個人所得稅和企業所得稅的實現，相應修改為：
public
class
taxpublic
static
double
calculateenterprisetax(double
income)}
稅收的公共類則修改如下：
public
class
taxop
public
double
gettax(double
income)}
客戶端的呼叫：
public
class",
op.gettax(1000));}}
從這兩個實現方案來看，**是大同小異的，但設計思想則迥然不同。它是物件導向和面向過程的區別，前者是將行為封裝為物件，而後者則直接對方法進行操作，同時又利用delegate委託來實現擴充套件。個人意見，我還是傾向於第一種方案，但後者至少也提供了一種思路。尤有甚者，我們也可以將委託理解為一種特殊的抽象，因為其本質是函式指標，它代表了一簇函式，從而對具有相同特性的行為進行了普遍意義的抽象。也許，這樣可以促進對委託的理解。
Strategy模式與Delegate委託
strategy 模式是對演算法的封裝。即使是乙個計算行為，如果其實現有其多樣性，為達到易擴充套件的目的，我們也有必要將其抽象出來，以介面的形式來定義。由於充分利用了物件導向的多型性，在呼叫該行為時，其具體的實現是在執行期決定的。以稅收計算為例，假定稅收策略分為個人所得稅，和企業所得稅。根據策略模式...
策略 Strategy 模式
strategy 模式也叫策略模式，是由 gof提出的 23種軟體設計模式的一種。strategy 模式是行為模式之一，它對一系列的演算法加以封裝，為所有演算法定義乙個抽象的演算法介面，並通過繼承該抽象演算法介面對所有的演算法加以封裝和實現，具體的演算法選擇交由客戶端決定 策略 strategy 模...
策略模式 Strategy
public context string strategytype df對策略模式的定義是這樣的 它定義了演算法家族，分別封裝起來，讓它們之間可以相互替換，此模式讓演算法的變化不會影響到使用演算法的客戶 main函式 abstract class strategy class concretest...