2017-12-22 22 views
1

カートの価格を出力するショッピングカートのアプリケーションに取り組んでいます。 私はこのカート、購入、またプランを持つことができます提供してカートを持つことができ、個々の製品の上に示すように製品Javaのデザインパターン - 商品やショッピングカートにオファーを申請する方法

public class Product { 

    private int id; 
    private String name; 
    private double price; 
    Offer offer; 
// getter setter 

    public double getPrice(int quantity) { 
     return offer.getPrice.... 
    } 

} 

public class Purchase { 

    Product product; 
    int quantity; 
// getter setter 

    public double getPrice() { 
     return product.getPrice(quantity); 
    } 

} 

public class Cart { 

    List<Purchase> purchase = new ArrayList<Purchase>(); 
    Offer offer; 
    Integer loyalityPoints; 
//getter setter 

    public double getTotal(){ 
     double total = 0; 
     for (Purchase purchase : purchase) { 
      total += purchase.getPrice(); 
     } 

     double finalPrice = offer.getPrice(total,....; 
     return finalPrice; 
    } 


} 

のための3つのクラスがあります。

当初私は提供工場を持っていると思った。 OfferPriceは抽象クラス&になることができます。その子はbuyonegetoneprice、buytwogetoneprice、50precentoffpriceを購入できますが、buyonegetonepriceの入力はqunatityとなり、50precentoffpriceの入力は価格のみです。

これは2つの異なる方法を意味しますが、OfferPriceの実装者は1つの実装にのみ関係します。

また、どのようにカートに表示されますか?カートでのオファーは、顧客ロイヤリティポイントまたは50パーセントオフなどに基づいています。

カートや個々の製品のためにこれらのオファーを拡張する方法でどのように設計するのですか?

答えて

-1

質問は少し一般的ですが、私はあなたにいくつかのアイデアを提供しようとします。

1)TDDを使用していない場合は、コードをテストできない場合は、何か悪いややこしいことをしているので、デザインを改善するのに役立ちます。

2)DI(Dependency Injection)をほとんどの場合使用して、新しいキーワードを避けてください。

3)未来を予測しようとしないでください。私たち人間は変化を予測するのが本当に悪いので、何かがリファクタリングを必要とすることが明らかになるまで複製を残してください。彼らが本当に必要とされる前に

4)デザインパターンを適用しないでください、理由は常に、継承オーバーポイント3

5)使用するインターフェイスは、組成物および委任と同じです。

1

あなたの例から、異なるオファー戦略が必要な場合があります。私の意見では、インターフェイスを使用することによって、これらの3つのクラスをすべて疎結合する必要があります。ここで

(あなたが動的にアプリケーションを停止することなく、アプリケーション全体のオファーを変更することができます)また、これはルールエンジンの恩恵を受けることができるもののように見えるなど

をOfferStrategyと製品ベースの提供などのサブクラス、価格ベースのオファーを作成することは私ですデザイン(各クラスのインターフェイス、内部ルールを使用して異なるオファーアルゴリズムをカプセル化するための戦略)のための提案: * Ixxxインターフェイス、<を表し、 - はを表す関係

IOFFER <ある - オファー、IProduct < - 製品、IPurchase < - 購入、IOfferStragegy < - OfferStrategy *(共通インタフェース方式と異なる実装) イカール< - カート カート製品や特典があります。ここで

は、これを行うためのメリット/理由あり:オファーとオファーの実装は変化し続けるしようとしていると仮定すると

  1. は、このようにインターフェースし、実行時に変更することが必要です。
  2. カートの価格はオファー戦略に基づいて決定されます
関連する問題