JAVA設計モデル——戦略モデル

ポリシー・モード
アルゴリズムファミリーを定義し、それぞれカプセル化して互いに置き換えることができます.このモードは、アルゴリズムを使用するお客様とは独立したアルゴリズムの変化をもたらします.        適用シーン1)複数のクラスは,表現動作が異なる場合にのみ区別され,Strategyモードを用いて実行時に具体的に実行する動作を動的に選択することができる.(例えばFlyBehaviorとQuackBehavior)2)異なるクラスの場合に異なるポリシー(アルゴリズム)を使用する必要があるか、またはポリシーは将来的に他の方法で実現される可能性がある.(例えばFlyBehaviorとQuackBehaviorの具体的な実装は任意に変更または拡張することができる)3)お客様(Duck)に具体的なポリシー(アルゴリズム)の実装の詳細を隠し、互いに完全に独立している.        メリットとデメリット:1)継承に代わる方法を提供し、継承のメリット(コード再利用)を維持するとともに、継承よりも柔軟になります(アルゴリズムは独立しており、任意に拡張できます).2)プログラムで多重条件遷移文を使用することを避け、システムをより柔軟にし、拡張しやすいようにする.3)大部分のGRASP原則と常用設計原則を遵守し、高集約、低カップリング.欠点:1)特定のポリシークラスごとに新しいクラスが生成されるため、システムが維持する必要があるクラスの数が増加します.
         具体的なケース
動作インタフェース:CreateIdea.java

package com.designpattern.strategy;

public interface CreateIdea {
	public void DoIdea();
}

具体的な動作:CreateIdeaA.java,CreateIdeaB.java

package com.designpattern.strategy;

public class CreateIdeaA implements CreateIdea{

	@Override
	public void DoIdea() {
		// TODO Auto-generated method stub
		System.out.println("I'm creating idea A!!");
	}

}

package com.designpattern.strategy;

public class CreateIdeaB implements CreateIdea{

	@Override
	public void DoIdea() {
		// TODO Auto-generated method stub
		System.out.println("I'm creating idea B!!");
	}

}

お客様:GetIdea.java

package com.designpattern.strategy;

public class GetIdea {
	private CreateIdea createIdea;
	
	public GetIdea(CreateIdea createIdea){
		this.createIdea = createIdea;
	}
	
	public void DoIdea(){
		this.createIdea.DoIdea();
	}
}

テストクラス:Test.java

package com.designpattern.strategy;

public class Test {
	public static void main(String[] args) {
		CreateIdeaA a = new CreateIdeaA();
		CreateIdeaB b = new CreateIdeaB();
		GetIdea getIdea = new GetIdea(a);
		getIdea.DoIdea();
		getIdea = new GetIdea(b);
		getIdea.DoIdea();
	}
}