2017-12-22 43 views
1

Ich arbeite an einer Warenkorb-Anwendung, die Preis des Wagens ausgeben wird. Ich habe 3 Klassen für diesen Wagen, Einkauf, ProduktJava Design Pattern - Wie man Angebote auf Produkt und Einkaufswagen anwenden

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; 
    } 


} 

Wie oben einzelnes Produkt gezeigt Angebot und Wagen auch Angebot haben haben kann.

Anfangs dachte ich an Angebot Fabrik. OfferPrice kann abstrakte Klasse sein & sein Kind könnte buyonegetoneprice, buytwegetapeprice, 50precentoffprice, aber dann Eingang für buyonegetoneprice wird Quanta sein und Preis und Eingabe für 50precentoffprice ist nur der Preis.

Dies bedeutet 2 verschiedene Methoden, aber Implementierer von OfferPrice betrifft nur eine Implementierung.

Auch wie könnte Angebot auf dem Wagen aussehen? Angebot auf dem Warenkorb kann auf Kundenbindungspunkte oder 50 Prozent oder etwas anderes basieren.

Wie können diese Angebote für Einkaufswagen und einzelne Produkte so gestaltet werden, dass sie erweiterbar sind?

Antwort

-1

Die Frage ist ein wenig generisch, aber ich werde versuchen, Ihnen ein paar Ideen zu geben.

1) Wenn Sie es nicht bereits tun, verwenden Sie TDD, das wird Ihnen helfen, Ihr Design zu verbessern, denn wenn der Code nicht testbar ist, tun Sie etwas schlecht oder schlampig.

2) Verwenden Sie DI (Dependency Injection) für fast alles, vermeiden Sie das neue Schlüsselwort.

3) Versuchen Sie nicht, die Zukunft vorherzusagen, wir Menschen sind wirklich schlecht darin, die Änderungen vorherzusagen, also lassen Sie die Verdopplung dort bleiben, bis es offensichtlich ist, dass etwas refactoring benötigt wird.

4) nicht Entwurfsmuster anwenden, bevor sie wirklich erforderlich sind, der Grund ist das gleiche wie Punkt 3

5) Verwenden Sie Schnittstellen, Zusammensetzung und Delegation über Vererbung, immer.

1

In Ihrem Beispiel benötigen Sie möglicherweise eine andere Angebotsstrategie. Meiner Meinung nach sollten Sie alle diese drei Klassen locker über Schnittstellen miteinander verbunden haben. Erstellen OfferStrategy und Subklassen wie Produkt-basierte Angebot, Preis basierend Angebot usw.

Dies auch, wie etwas aussieht, die von Rules-Engine profitieren können (Sie dynamisch Angebot für gesamte Anwendung ohne Unterbrechung der Anwendung ändern kann)

Hier ist mein Vorschlag für die Gestaltung (Schnittstellen für jede Klasse, die Strategie verschiedene Angebote Algorithmen verkapseln, die intern Regeln verwenden): * Ixxx stellt Schnittstelle, < - stell ein Beziehung ist

IOffer < - Angebot, IProduct < - Produkt, IPurchase < - Ankauf, IOfferStragegy < - OfferStrategy * (Verschiedene Ausführungen mit Common-Interface-Methode) ICART < - Wagen Wagen Produkte und Angebote haben.

Hier sind die Vorteile/Grund, dies zu tun:

  1. Unter der Annahme, dass das Angebot und Angebot Umsetzung zu halten gehen zu ändern braucht also Schnittstellen und die Fähigkeit zur Laufzeit zu ändern.
  2. Der Warenkorbpreis wird auf Basis Angebotsstrategie
festgelegt
Verwandte Themen