Come progettare le classi per un semplice esempio di carrello degli acquisti utilizzando Strategy Design Patterns

Dato che stai imparando OOP ti aiuto con la parte busines:

Hai sconti specifici sui prodotti (strategia di sconti) che dipendono dalla quantità di cartoncino

Milk $0.60
Buy 3 Milk for the price of 2 = discount is 0.60 per 3 Milk = 0.60*int(cartitem.quantity / 3)

cart has 7 milk á 0.60 = 4.20
minus milk-discount int(quanty/3) * 0.60 = int(7/3) * 0.60 = 2 * 0.60 = 1.2


4.20
- 1.2
= 3.00

Questo dovrebbe darti informazioni sufficienti per progettare classi Product, ProductDiscountStrategy, Cart, CartItem

Sì, un problema comune nei siti di e-commerce, non facilmente risolvibile se si hanno molti prodotti e offerte.

Il mio approccio è di dare ad ogni articolo un prezzo piuttosto che avere un solo prezzo totale. Pensala come una ricevuta che ti mostra quali oggetti sono stati ridotti.

Avere un'offerta di classe che include gli elementi richiesti nel carrello per l'offerta da applicare e una funzione di determinazione del prezzo che prende il paniere completo e l'articolo al prezzo.

seleziona tutte le offerte applicabili al tuo carrello, per ogni articolo chiama ogni funzione di determinazione del prezzo e applica l'offerta migliore.

Ora noterai anche che le offerte che tutti comprendono come comprarne una prendi due, sono in realtà più complicate. vale a dire comprarne uno (che non è stato precedentemente utilizzato per ottenerne uno gratis) e ottenerne uno gratuito.

Passando l'intero paniere (con i prezzi, io chiamo una ricevuta) nella funzione di determinazione del prezzo, hai abbastanza informazioni per essere in grado di capire questo tipo di cose e applicare il prezzo corretto per articolo.

@Milke I tried to go for that approach but I cannot seem to be able to implement an Item Class for each separate items.

Lezioni apprese, in primo piano:

• Non analizzare eccessivamente. È chiaro che un oggetto (prodotto) ha un nome e un prezzo. Il resto si evolverà con il design generale.
• Ignora equazioni e amp; ToString è spesso utile. ToString in particolare quando sai che c'è un output, come una ricevuta. Ogni classe dovrebbe preoccuparsi solo di come produrre se stesso.
  Le classi di raccolta
  • usano uguali.
  • l'uguaglianza "identità" è comune nel mondo reale.
  • Principio della singola responsabilità al suo massimo.
• Segni di buon design:
  • piccole classi
  • piccoli metodi
  • più classi perché ognuna ha una "responsabilità unica"
  • Questi tratti tendono ad accadere semplicemente come conseguenza di fare delle buone lezioni autosufficienti.

NOTA: considera questo esempio come pseudo codice. Non ho codificato Java da un po '.       Tralascio cose importanti come il controllo degli argomenti nulli.

.

public class Product {
    public Product (string name, decimal price) {
       this.Price = price;
       this.Name = name;
    }

    public decimal GetPrice() { return this.Price; }

    // nobody overrides Equals and ToString. but you should!

    public override bool Equals ( object otherProduct ) {
       return this.Name.Equals(otherProduct.Name);
    }

    public override string ToString () {
       return name + "   " + price;
    }
}

public class Cart {
    protected List<Product> items;

    public void AddItem( Product newItem ) {  }

    public decimal CartTotal() {
       decimal total = 0;

       foreach (Product thing in items) { total += thing.GetPrice(); }
       return total;
    }


}

Cosa succede se compro più oggetti? Bene, aggiungete ognuno - AddItem () - quindi nessun problema. Poi vedo che ho bisogno di sapere quanti di ogni tipo calcolare il costo totale. Come implementare?

• Il prodotto è solo una "cosa". non è il posto giusto Un prodotto conosce se stesso. Non dovrebbe conoscere il carrello e gli altri contenuti.
• Il carrello ha una lista di tutto. Questa è la classe giusta.
  • un metodo, probabilmente privato, per sommare quantità. Anche i metodi devono seguire SRP.
  • Un dizionario di tipi di prodotto: contare. Dall'esperienza mi piace questo. E il codice trarrà vantaggio dalla sostituzione di Product.Equals.

.

public class Cart {
   protected Dictionary<Product, int> items;
   // I think we can throw away the List<Product>

   public void AddItem ( Product newItem ) {
      if ( ! items.Contains(newItem) )    // SRP in action
         items.Add(newItem);

      items[newItem].count++;
   }

   public decimal CartTotal() {
      foreach ( thing in items ) { 
         total += items[thing].GetPrice * items[thing].count;
      }
   }

   // code in "cart"/"shopping" terminology. aka Domain Specific Language - DSL.
   public string Receipt() { return this.ToString(); } 

   public override string ToString() {
      string me = "";

      foreach ( thing in items ) {
         me += items[thing].ToString() + "\n";   // SRP in action
      }

      me += "\n\n Total: " + CartTotal();
      return me;
   }

}