背景
モールレジシステムをショッピングすると、更新を受信すると、顧客は単価と数量を購入した顧客に応じて収集する必要がありますどのくらいのお金を計算するために、レジのソフトウェアが必要であると言います。また、追加の割引機能に対する顧客要求のバージョンをやって、そして後に完全な機能をサポートする必要性を減らします。
最初に私はこのアイデアに関連する種類に応じて共通のインタフェースを作成することです現在使用されているどのような支払モードの決定し、受信に必要な現金を計算するのに対応する機能を選択します。
シンプルなファクトリパターン
ので、このようなシナリオは比較的単純なファクトリパターンが適用されることを、簡単な工場出荷時のパターンを学習する前に、その次のコードを持って、親クラスの料金を作成します。
public abstract class CashSuper {
private int nums;
private double price;
protected abstract double acceptCash(double money);
}
そして、通常の支払モード、未収割引セーブモードとフルモード3クラスを定義
class NormalCash extends CashSuper {
@Override
protected double acceptCash(double money) {
return money;
}
}
class RebateCash extends CashSuper {
private double rebate;
public RebateCash(double rebate) {
this.rebate = rebate;
}
@Override
protected double acceptCash(double money) {
return money * rebate;
}
}
class ReturnCash extends CashSuper {
private double moneyCondition = 0.0;
private double moneyReturn = 0.0;
public ReturnCash(double moneyCondition, double moneyReturn) {
this.moneyCondition = moneyCondition;
this.moneyReturn = moneyReturn;
}
@Override
protected double acceptCash(double money) {
return money - Math.floor(money / moneyCondition) * moneyReturn;
}
}
そして、その上にコレクション機能を作成します
class CashFactory {
public static CashSuper createAcceptCasg(int type) {
CashSuper cashSuper;
switch (type) {
case 0:
cashSuper = new NormalCash();
break;
case 1:
cashSuper = new RebateCash(0.7); // 打七折
break;
case 2:
cashSuper = new ReturnCash(100, 50); // 满100减50
break;
default:
cashSuper = new NormalCash();
}
return cashSuper;
}
}
このモードでは、それはこの需要に対応することができますが、このモードが唯一のオブジェクトを作成した問題を解決することであり、植物自体も、すべての充電方法を含んでいるため、モールは割引やリベート規模の量を頻繁に変更する可能性があり、各メンテナンスがそれが最善の方法ではありませんので、変更する必要があるか、工場を拡張するには、そのコードのニーズを展開するために再コンパイルすること、それは本当に、非常に悪いアプローチです。
戦略モード
アルゴリズムが頻繁に変化の顔は、あなたは戦略パターンを使用する必要があります。
事件は、顧客に影響を与えないとき** Strategyパターンは、アルゴリズムのファミリーを定義し、それらをカプセル化するので、彼らはお互いを置き換えることができ、このモードは、アルゴリズムのuの変化を可能にする。**
次のようにコードは次のとおりです。クライアントは、このコードを呼び出す必要があります完全な、しかし、使用するアルゴリズムを決定するためにクライアントを必要とします
class CashContexts {
private CashSuper cashSuper;
public CashContexts(CashSuper cashSuper) {
this.cashSuper = cashSuper;
}
public double getReesult(double money) {
return cashSuper.acceptCash(money);
}
}
クライアント:
public static void main(String[] args) {
CashContexts cashContexts;
double money = 100;
int type = 0;
switch (type) {
case 0:
cashContexts = new CashContexts(new NormalCash());
break;
case 1:
cashContexts = new CashContexts(new RebateCash(0.7));
break;
case 2:
cashContexts = new CashContexts(new ReturnCash(100,50));
break;
default:
cashContexts = new CashContexts(new NormalCash());;
}
double reesult = cashContexts.getReesult(money);
System.out.println(reesult);
}
Strategyパターンは、単純なファクトリパターンと組み合わせ
class CashContextt {
private CashSuper cashSuper;
public CashContextt(Integer type) {
switch (type) {
case 0:
cashSuper = new NormalCash();
break;
case 1:
cashSuper = new RebateCash(0.7);
break;
case 2:
cashSuper = new ReturnCash(100,50);
break;
default:
cashSuper = new NormalCash();
}
}
public double getResult(double money) {
return cashSuper.acceptCash(money);
}
}
実際には、戻って考えて、戦略モードは、これらの作業を完了するために、同じ方法であり、ビューの概念的な観点から、一連のアルゴリズムを定義する方法であるが、それは同じメソッド呼び出しすべてのアルゴリズムを使用することができ、同じ量を達成していません様々なクラスおよびユーティリティクラス間の結合を低減するためのアルゴリズム