最もよく使われる設計モード---策略モード(C++実現)

ポリシーモードも非常に一般的な設計モードであり、複雑ではありません.次に、このパターンを見てみましょう.
定義:ポリシー・モードは、一連のアルゴリズムを定義し、各アルゴリズムをカプセル化し、互いに置き換えることもできます.ポリシー・モードは、アルゴリズムを使用するお客様とは独立して変化させます.
ロール:抽象ポリシーロール(Strategy):抽象ポリシークラス.具体的なポリシーロール(ConcreteStrategy):継続的に関連するアルゴリズムと動作がカプセル化されています.環境ロール(Context):ポリシークラスの参照を持ち、最終的にクライアントに呼び出されます.
UML図:
                
事例:(この事例は1つのネットワーク設計モデルの面接問題から改編された)
今あなたがデザイナーであれば、エアコンを設計しています.しかし、あなたたちのエアコンは3つのモードをサポートしなければなりません.冷風モード(ColdWind)、熱風モード(WramWind)、無風モード(NoWind).ColdWindモードを選択すると、冷風が送られます.WarmWindモードを選択すると、熱風が送られます.NoWindモードを選択した場合、エアコンは何もしません.エアコンのアプリケーションをどのように設計するかを考えますか?もし将来エアコンが新しいモードをサポートする必要があるとしたら?
この面接問題は、実際には様々なモデルで実現できますが、ここでは戦略モデルが適切であることを理解しています.冷風モード,熱風モードおよび無風モードを種々の異なるアルゴリズムとして理解できる.ポリシー・モードが非常に一致していることは明らかです.
ここColdWind,WramWind,NoWindは実はConcreteStrategyです.IWndは抽象戦略クラスである.戦略クラスをカプセル化し始めました

#include <iostream>
using namespace std;
#define  free_ptr(p) \
	if(p) delete p; p = NULL;

class IWind{
public:
	virtual ~IWind(){};
	virtual void blowWind() = 0;
};

class ColdWind : public IWind{
public:
	void blowWind(){
		cout<<"Blowing cold wind!"<<endl;
	};
};

class WarmWind : public IWind{
public:
	void blowWind(){
		cout<<"Blowing warm wind!"<<endl;
	}
};

class NoWind : public IWind{
public:
	void blowWind(){
		cout<<"No Wind!"<<endl;
	}
};

次にwindmodeのクラスを実現し、windシリーズの環境クラスとして使用します.

class WindMode{
public:
	WindMode(IWind* wind): m_wind(wind){};
	~WindMode(){free_ptr(m_wind);}
	void blowWind(){
		m_wind->blowWind();
	};
private:
	IWind* m_wind;
};

最後のクライアントコード:

int main(int argc, char* argv[])
{
	WindMode* warmWind = new WindMode(new WarmWind());
	WindMode* coldWind = new WindMode(new ColdWind());
	WindMode* noWind = new WindMode(new NoWind());

	warmWind->BlowWind();
	coldWind->BlowWind();
	noWind->BlowWind();

	free_ptr(warmWind);
	free_ptr(coldWind);
	free_ptr(noWind);
	system("pause");
	return 0;
}

(この例はネット上でもコマンドモードで実装されている.コマンドモードは私の後のブログを見てください.冷風、熱風、無風をコマンドとしています.もちろんこれは別の考え方ですが、コマンドモードを採用すればいいと思います.クラスの数はそれに応じて増え(シリーズのコマンドクラスを増やす)、追加のオーバーヘッドになると思います.新しいモードを追加すると、追加するクラスが多すぎます.多かれ少なかれそんなに賢明ではない.だから個人的にはここで戦略モデルがもっといいと思います.)
総じて言えば、戦略モデル:
利点:1、ポリシー・モードを使用すると、多重条件遷移文の使用を回避できます.多重転送文はメンテナンスしにくい.2、策略モードはあなたにダイナミックにオブジェクトの行为を変えることができて、ダイナミックに策略の欠点を修正します:1、クライアントはすべての策略のクラスを知っていなければならなくて、そして自分でどの策略のクラスを使うことを决めます.2、クラスが多すぎる---ポリシーモードは多くのポリシークラスをもたらし、各具体的なポリシークラスは新しいクラスを生成します.(これはメタモードでクラス過多を克服できる)