Esiste un modello di progettazione applicabile ai modelli di sconto?

Se il problema è che devi applicare più sconti, in determinate circostanze, potresti prendere in considerazione la Catena di responsabilità modello.

In poche parole, si passa l'informazione che si desidera elaborare nel primo processore, e decide da lì se passarla a ulteriori processori prima di restituire il risultato.

In questo modo è possibile modificare la struttura e la sequenza dei processori senza mai modificare il codice chiamante.

I modelli di strategia, decoratore e stato mi sono stati indicati come potenziali punti di partenza. Lo stato potrebbe essere particolarmente utile per 2 o 3, poiché 2 dipende dallo stato dell'ordine e 3 dipende dallo stato del cliente entro un periodo di tempo. Strategia e Decoratore si distinguono per gli altri, dal momento che è possibile utilizzare la strategia per implementare più algoritmi di calcolo del prezzo dell'ordine e decoratore per aggiungere nuovi sconti all'ordine.

Tuttavia, ricorda che i modelli di progettazione sono solo modelli. Potrebbe non esserci un unico modello applicabile, ma piuttosto un sistema di schemi. Considera anche di apportare modifiche ai modelli descritti per adattarli meglio alla tua soluzione. È meglio avere un buon design che forzare un modello in cui non necessariamente aiuta solo per poter dire di avere uno schema.

Bene, progetterei un modello di sconto come una coppia "Precondition" e "Discount", dove "Precondition" è una classe con metodi

  bool IsFulfilled(Customer c);

o / e

  bool IsFulfilled(Customer c, Order o);

e lo sconto ha un metodo void ApplyTo(Customer c) . Questo ti dà la possibilità di combinare qualsiasi tipo di precondizione con qualsiasi tipo di sconto (penso che questa sia una forma di "pattern di bridge").

Se hai un numero fisso di precondizioni, allora puoi risolvere il problema costruendo sottotipi specifici (modello di strategia). Tuttavia, quando le condizioni preliminari possono essere molto complesse, con istruzioni logiche come AND, OR e NOT, è meglio implementare un tipo di interprete di regole per le condizioni. Le regole possono essere una stringa di testo semplice scritta in un semplice "dominio specifico".

Lo stesso vale per la classe "Sconto", puoi avere alcuni sottotipi per diversi tipi di sconti o un approccio generale in cui le regole di sconto sono date in forma di testo, valutate da qualche interprete.

• Probabilmente è necessaria un'interfaccia IDiscount in quanto tutti gli sconti sono la stessa cosa e vorremmo trattarli concettualmente come sconti generici.

• La classe "ordine del cliente" probabilmente richiede una raccolta di sconti. Elenco? Hash? Lista collegata? Non importa, ancora. Gli sconti si applicano all'acquisto, non al cliente!

• Mantieni separata l'istanza di Sconto da Cliente, Carrello, Cronologia, ecc. Cambierà molto, come sottolineato da @jfrankcarr.

• Probabilmente una classe diversa per ogni sconto in quanto l'algoritmo e i parametri per ogni sconto variano in modo selvaggio e imprevedibile.

• Vedo un sacco di gestione degli eventi poiché il calcolo dello sconto risponde alle modifiche del carrello degli acquisti e viceversa.

Applicazione pattern di progettazione

• Vedo un strategy pattern . IDiscount è l'interfaccia per implementare diversi algoritmi di sconto.

• Vedo un factory . Certamente non un% co_de in piena regola, ma una singola classe a questo punto nell'analisi. Ragionevolmente, ci deve essere un singolo luogo in cui vi è un contesto sufficiente per decidere quali sconti applicare e quindi crearli. Una classe. Se le regole per l'applicazione degli sconti in seguito esplodono a causa di una parte fungo del Dipartimento Marketing, qualsiasi logica aggiuntiva di costruzione di sconti deve ancora riunirsi in questa classe di fabbrica base, credo.

• Posso vedere abstract factory pattern . Questo non si esclude a vicenda per l'idea Chain of Responsibility . Invece di iterare una collezione di sconti, ogni sconto chiama il prossimo. In questo caso, la classe "ordine del cliente" non contiene una raccolta di sconti.

• Il fattore "hmmmm ...." in Chain of Responsibility, penso, è che ogni sconto abbia un riferimento al successivo. L'implicazione è che l'ordine conta. Che non è il caso Inoltre, il concetto che CoR incarna è che un oggetto non può gestire la richiesta così è passato "fino alla successiva autorità superiore". Il nostro modello è diverso L'unica richiesta è da calcolare. Ogni sconto fa questo. L'output o l'effetto può essere nullo ma ogni sconto viene calcolato. Io istintivamente mi chino verso una fedeltà più alta del mondo reale.

Ipotesi

• Gli sconti si basano sul carrello della spesa corrente e / o sulla cronologia degli acquisti
• potrebbero essere applicati zero o più sconti. Non ci sono sconti che si escludono a vicenda
• Il calcolo corretto non dipende dall'ordine in cui vengono applicati gli sconti.

Che cosa cambia, cosa rimane lo stesso?

• Gli sconti sono molto diversi. Numero e tipo di parametri diversi per completare ciascuna regola.

• Gli argomenti per gli sconti qualificanti cambiano quando il carrello acquisti cambia.

• Il numero di sconti disponibili cambia

• Gli sconti che questo cliente qualifica per le modifiche man mano che cambia il carrello acquisti.

• La cronologia degli acquisti non cambia nel contesto di questo acquisto

• Il costo totale cambia in modo dinamico in funzione delle linee di acquisto e degli sconti applicati.

• Dopo l'applicazione iniziale, l'uscita di uno sconto potrebbe cambiare, ad esempio, come cambia la quantità d'acquisto.

Logicamente, un modello di sconto può essere qualsiasi cosa , quindi non puoi presumere che tu possa programmare tutti i casi in anticipo. Né chiunque può rispondere alla tua domanda essere completamente sicuro di ciò di cui hai effettivamente bisogno. Tuttavia, assumendo che si ottengano i soliti tipi di sconti trovati nel mondo reale ...

Una grande domanda è se gli sconti saranno programmati o se vuoi che gli utenti li inseriscano. Come accennato in precedenza, non è possibile mai averli programmati, ma di solito l'obiettivo è cercare di renderlo più un inserimento di dati simile a casi comuni, piuttosto che programmarli tutti. Questo si applica in parte anche se i programmatori sono utilizzati per creare tutti gli sconti.

Martin Fowler menziona "Metodo di istanza individuale" in "Modelli di analisi: modelli di oggetti riutilizzabili" come parte di come implementare "Regole di registrazione" per i sistemi di contabilità, ma le regole sembrano abbastanza simili alla tua. Darei maggiori dettagli ma è un lavoro protetto da copyright e

Per un'interfaccia utente, devi creare casi d'uso abbastanza semplici oppure creare un interprete e un generatore di query. Forse entrambi, uno per casi semplici e uno più avanzato. Se si scrive un interprete, questo è probabilmente un buon caso per l'utilizzo del pattern Interpreter, dal momento che è relativamente semplice da codificare rispetto a un generatore di parser, e il tempo di analisi più lento probabilmente non avrà molta importanza. (Se ti piace usare i parser generatori non lasciarmi fermare).

Non provare comunque a fare tutto con un interprete - ad un certo punto stai programmando nel tuo linguaggio scadente, quindi potresti anche usare uno vero. Se il tuo linguaggio interpretato supporta le funzioni (probabilmente dovrebbe supportare chiamarle - definirle è dubbio) quelle possono essere codificate in un linguaggio reale. Non andare più avanti su questa strada di quello che devi.

Indipendentemente da ciò che fai, alla fine qualcuno vorrà che lo sconto sia basato sul fatto che siano stati acquistati entro 30 giorni lavorativi da una promozione - dove i giorni lavorativi contano solo se non ci sono festività nella regione definite dal codice postale del negozio o il codice postale del cliente. Quindi non cercare di progettare in anticipo il sistema perfetto - supponi che a volte dovrai scrivere codice per nuovi tipi di sconti e progettare di conseguenza.

C'è qualche punto in cui ti stai chiedendo se esiste un modello utile per questo? Che tipo di schema è richiesto: strutturale o comportamentale?

Idealmente, se dovessi scrivere un software per questo, sarà sufficiente un algoritmo . Una semplice funzione che calcola lo sconto totale come segue:

cart.calculateDiscount(productVector);

Non hai proprio bisogno di qualcosa di più di questo!

Per chiarire: capisco che ci saranno molte regole - la più fondamentale di tale rappresentazione dovrebbe essere sotto forma di una base di regole (set di attributi di dati e sconto risultante contro di essa) e la funzione come sopra lo itererà per calcolare esso. Se le regole vengono aggiunte o rimosse, non dovresti modificare il codice, basta cambiare la rule base.

Il pattern sarà richiesto solo se abbiamo bisogno che oggetti diversi abbiano bisogno di accedere alle API l'uno dell'altro o comunicare per mettere in atto un'attività.

PS: Pensaci: quando il firewall elabora i pacchetti e passa o rifiuta i pacchetti (o lo modifica), quale modello di progettazione utilizza? La risposta è NESSUNA di quanto sopra descritto!