注意事項！

学習と執筆の文章.間違った内容や不実な説明があれば教えてください.😁
ポリシー・モードまたはポリシー・モードは、実行中にアルゴリズムを選択できる動作ソフトウェア設計モードです.ポリシー・モードは、特定のシリーズのアルゴリズムを定義し、各アルゴリズムをカプセル化し、これらのアルゴリズムをこのシリーズ内で互いに置き換えることができるようにします.ウィキペディア

概要

ポリシー・モードは、プログラムまたはソース・コードの実行中にアルゴリズムを選択するための設計モードです.ポリシー・モードを適用することで、開発者が必要とする領域内で、事前定義およびカプセル化されたアルゴリズムを置き換え、選択できます.要するに、これは設計方法であり、特定の領域でアルゴリズムを選択して適用することができます.

例

1棟に自動販売機があります.ボタンを押すと、そのボタンに合った飲み物が自動販売機から飛び出します.

ポリシー・モードを適用する前に

public class DrinkMachine{
	public DrinkMachine(String button){
    	String drink;
    	if(button == "탄산"){
        	drink = "탄산음료";
        }else if(button == "이온음료"){
        	drink = "이온음료";
        }else{
        	drink = "물";
        }
        return drink;
    }
}

上記のコードに示すように、ポリシーモードを使用しない場合は、if-elseブロックの制御コードを使用する必要があります.これにより、コードの柔軟性が低下し、1つの方法に論理を追加する必要があります.ここでは、仮に自販機の飲み物が入っていて、コーヒー、ジュースが入っていたとします.
上記のコードがコーヒーと果実酒のために追加のif-elseコードブロックを記述する必要がある場合、このような簡単なコードではなく、100行1000行の複雑な論理ではCopy-Pasteを実現することはほとんど不可能である.

ポリシー・モードの適用後

飲料のインタフェース化は、次のように行います.

public interface Beverage{
	void vend();
}

public class Soda implements Beverage{
	private final String DRNIK = "탄산음료";
    @override
    public void vend(){
    	return DRINK;
    }
}

public class Coffee implements Beverage{
	private final String DRINK = "커피";
    @override
    public void vend(){
    	return DRINK;
    }

上のように、飲み物をクラスに変えて、自動販売機に貼ります.

public class VendingMachine{
	public String vend(Beverage beverage){
    	return beverage.vend();
    }
}

public class Building{
	public static void main(String[] args){
    	VendingMachine vendingMachine = new VendingMachine();
        // 자판기 설치.
        String soda = vendingMachine.vend(sodaButton());
        // soda 버튼을 누르면 탄산음료 추출.
        String coffee = vendingMachine.vend(coffeeButton());
        // coffee 버튼을 누르면 커피 추출.
    }
    
    public static Beverage sodaButton(){
    	return new Soda();
    }
    
    public static Beverage coffeeButton(){
    	return new Coffee();
    }
}

自動販売機のメニューや交換するメニューに追加するには、飲み物(アルゴリズムを定義)を作成し、異なるボタン(ポリシー)を押すだけです.各分野で異なるポリシーを採用する方法をポリシーモードと呼ぶ.
コード修正発生時
ポリシー・モードが適用されていない場合>>if-elseブロックを追加
アプリケーション戦略モード>>Class追加

長所

戦略モデルの優位性
1つ目の方法は、既存の方法を直接変更することなく、新しいアルゴリズムを追加することです.(OCP原則)
2つ目の利点はメンテナンスです.上のコードに新しいメニューを追加し、既存のメニューを変更した場合、既存のコードは変更されません.ただし、ポリシーモードを使用していないコードでは、既存のコードを修正すべきでしょうか?
例のコードは非常に簡単で、実際にはポリシー・モードは必要ありませんが、実際のプロジェクトに1000行のコードと2000行のコードのブランチがある場合は、メンテナンスのリスクが大きくなります.

短所

唯一の利点は技術ではありません.
複数のアルゴリズムを有するプログラムは、従来のif-else構文に比べて、より楽で簡潔に見えます.すなわち,すべての場合に万能コードが用いられるわけではない.極端な例を挙げると、アルゴリズムの変化がなく、1つの使用領域しかない場合は、ポリシーモードを使用する必要がなく、直接適用すればよいのではないでしょうか.アプリケーションが簡単であればあるほど、コードの複雑さが高くなります.

n/a.結論

戦略モデルは、クライアントのニーズ変更と、異なる分野で異なるアルゴリズムを適用する場合の発光モデルです.もちろんすべての場合に通用する万能技術ではなく、状況に応じてどのようなモデルを使用するか、どのような技術を応用するかは開発者が責任を負い、その選択の責任と成果も開発者が責任を負う.