設計モード-ポリシーモード(共通)

紹介:
ソフトウェア開発でもよく似たような状況に遭遇し、ある機能を実現するには多くのアルゴリズムやポリシーがあり、環境や条件によって異なるアルゴリズムやポリシーを選択して機能を完成することができます.検索、ソートなど.1つの一般的な方法は、複数のアルゴリズムを1つのクラスに書き、各方法は特定の検索アルゴリズムに対応する複数の方法を提供する.もちろん、これらの検索アルゴリズムを統一的な方法にカプセル化し、if...else...やswitch-caseなどの条件判断文で選択することもできます.この2つの実装方法はいずれもハードコーディングと呼ぶことができる.しかし、多くのアルゴリズムが1つのクラスに集中すると、このクラスは肥大化し、このクラスのメンテナンスコストが高くなり、エラーが発生しやすくなります.新しいソートアルゴリズムが必要な場合は、パッケージアルゴリズムクラスのソースコードを変更する必要があります.これは明らかにOCPの原則と単一の職責の原則に違反している.これらのアルゴリズムまたはポリシーを抽象化すると、異なるアルゴリズムまたはポリシーに異なる実装クラスがあり、プログラムクライアントが異なる実装オブジェクトを注入することによってアルゴリズムまたはポリシーの動的置換を実現することができ、このような拡張性、メンテナンス性がより高く、これがポリシーモードである.
定義:
ポリシー・モードは、一連のアルゴリズムを定義し、各アルゴリズムをカプセル化し、互いに置き換えることもできます.ポリシー・モードは、アルゴリズムを使用するお客様とは独立して変化させます.
シーンを使用:
1.同一タイプの複数の処理方式に対して、具体的な行為に差がある場合のみ.2.複数の同じタイプの操作を安全にカプセル化する必要がある場合.3.同じ抽象クラスに複数のサブクラスが存在し、if-elseまたはswitch-caseを使用して特定のサブクラスを選択する必要がある場合.
具体的な実装:
交通機関によって料金の計算規則が異なり、バスや地下鉄を例に挙げると

public class StrategyModel {

    CalculateStrategy calculateStrategy;

    public void main(String[] args) {
        StrategyModel strategyModel = new StrategyModel();
        strategyModel.setStrategy(new BusStrategy());
        System.out.println("   " + strategyModel.calculatePrice(10) + "  ");


    }

    public void setStrategy(CalculateStrategy calculateStrategy) {
        this.calculateStrategy = calculateStrategy;
    }

    public int calculatePrice(int km) {
        return this.calculateStrategy.calculatePrice(km);
    }

    public interface CalculateStrategy {
        /**
         *        
         *
         * @param km
         * @return
         */
        int calculatePrice(int km);
    }

    public class BusStrategy implements CalculateStrategy {

        @Override
        public int calculatePrice(int km) {
            return km * 5;
        }
    }


    class SubwayStrategy implements CalculateStrategy {

        @Override
        public int calculatePrice(int km) {
            return km * 10;
        }
    }

}

ポリシーモードは主にアルゴリズムを分離するために用いられ,同じ動作抽象の下で異なる具体的な実装ポリシーがある.このモードは,抽象を定義し,異なる実装を注入し,良好な拡張性を達成する開閉原則を良く実証した.
メリット:
構造がはっきりしていて、簡単な直感を使っています.結合充填はそれに応じて低く、拡張が便利である.操作パッケージもより徹底的で、データはより安全です.
欠点:
戦略が増えるにつれて、サブクラスも多くなります.
参考:「Androidソースデザインモデル解析と実戦」