Esiste un modello di progettazione che si applicherebbe ai modelli di sconto?

Esistono modelli di progettazione noti per l'implementazione di modelli di sconto?

Per modelli di sconto, intendo quanto segue:

1. Se un cliente acquista il Prodotto X, il Prodotto Y e il Prodotto Z, ottiene uno sconto del 10% o $ 100.

2. Se un cliente acquista 100 unità del Prodotto X, ottiene uno sconto del 15% o $ 500

3. Se un cliente ha portato nell'ultimo anno oltre $ 100.000, ottiene uno sconto del 20%

4. Se un cliente ha acquistato 2 unità di Prodotto X, ottiene 1 unità di Prodotto X (o Prodotto Y) gratuitamente.

5. ...

Esiste un modello generico che può essere applicato per gestire tutti gli scenari di cui sopra? Sto pensando ad alcuni modelli, ma non riesco a trovarne uno generico.

Se il problema è che è necessario applicare più sconti, in determinate circostanze, è possibile prendere in considerazione il modello di catena di responsabilità .

In poche parole, si passano le informazioni che si desidera elaborare nel primo processore e decide da lì se passarle 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 si distinguono per me come potenziali punti di partenza. Lo stato può 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 Decorator si distinguono per gli altri, poiché è 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 schema 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 piuttosto che forzare un modello in cui non è necessariamente utile solo per il gusto di poter dire che hai un modello.

Bene, progetterei un modello di sconto come coppia "Precondizione" e "Sconto", dove "Precondizione" è 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 "schema a ponte").

Se si dispone di un numero fisso di condizioni preliminari, è possibile risolvere il problema creando sottotipi specifici (modello di strategia). Tuttavia, quando le tue condizioni preliminari possono essere molto complesse, con istruzioni logiche come AND, OR e NOT, potresti implementare meglio un qualche tipo di interprete di regole per le condizioni. Le regole possono essere una stringa di testo semplice scritta in un semplice "linguaggio specifico del dominio".

Lo stesso vale per la classe "Sconto", è possibile avere alcuni sottotipi per diversi tipi di sconti o un approccio generale in cui le regole di sconto sono fornite in forma testuale, valutate da un interprete.

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

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

• Mantieni la creazione dell'istanza di Discount separata dal Cliente, dal Carrello, dalla 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 molta gestione degli eventi poiché il calcolo dello sconto risponde alle modifiche del carrello e viceversa.

Applicazione del modello di progettazione

• Vedo a strategy pattern. IDiscount è l'interfaccia per l'implementazione di diversi algoritmi di sconto.

• Vedo a factory. Certamente non una vera e propria abstract factory pattern, ma una singola classe a questo punto dell'analisi. Ragionevolmente, ci deve essere un unico posto in cui esiste 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 festa di funghi del dipartimento marketing, qualsiasi ulteriore logica di costruzione degli sconti deve ancora fondersi in questa classe di fabbrica di base, penso.

• Posso vedere Chain of Responsibility. Questo non si esclude a vicenda factoryall'idea. Invece di ripetere una raccolta di sconti, ogni sconto chiama il ragazzo successivo. La classe "ordine del cliente" non contiene una raccolta di sconti in questo caso.

• Il fattore "hmmmm ...." in Chain of Responsibility, penso, è che ogni sconto ha un riferimento al successivo. L'implicazione è che l'ordine conta. Non è così. Inoltre, il concetto che il CdR incarna è che un oggetto non può gestire la richiesta, quindi viene passata "alla successiva autorità superiore". Il nostro modello è diverso. L'unica richiesta è di calcolare. Ogni sconto fa questo. L'output o l'effetto possono essere nulli ma viene calcolato ogni sconto. Istintivamente mi sposto verso una fedeltà del mondo reale superiore.

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 reciprocamente esclusivi
• Il corretto calcolo non dipende dall'ordine in cui vengono applicati gli sconti.

Cosa cambia, cosa rimane uguale?

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

• Gli argomenti per gli sconti idonei cambiano al variare del carrello.

• Il numero di sconti disponibili cambia

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

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

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

• Dopo l'applicazione iniziale, l'output di uno sconto può cambiare, come ad esempio la quantità di acquisto cambia.

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

Una grande domanda è se gli sconti saranno programmati o se si desidera che gli utenti li inseriscano. Come accennato in precedenza, non è mai possibile programmarli, ma di solito l'obiettivo è quello di provare a renderlo più immissione di dati come per i casi comuni, piuttosto che programmarli tutti. Ciò si applica in una certa misura anche se i programmatori vengono 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 le "Regole di registrazione" per i sistemi contabili, ma le regole sembrano abbastanza simili alle tue. Darei maggiori dettagli ma è un'opera protetta da copyright e

Per un'interfaccia utente, è necessario elaborare 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 scrivi un interprete, questo è probabilmente un buon caso per usare il modello Interprete, poiché è relativamente semplice da programmare rispetto a un generatore di parser, e il tempo di analisi più lento probabilmente non importerà davvero. (Se ti piace usare i generatori di parser non lasciarmi fermare).

Tuttavia, non provare a fare tutto con un interprete - a un certo punto stai solo programmando nel tuo linguaggio scadente, quindi potresti anche usarne uno vero. Se il tuo linguaggio interpretato supporta funzioni (probabilmente dovrebbe supportare chiamarle - definirle è dubbio) quelle possono essere codificate in un linguaggio reale. Non andare più avanti di questa strada di quanto tu debba fare.

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

C'è qualche punto è chiedersi se esiste un modello utile per questo? Che tipo di modello è richiesto - strutturale o comportamentale?

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

cart.calculateDiscount(productVector);

Non hai assolutamente bisogno di altro!

Per chiarire: capisco che ci saranno molte regole - la maggior parte di tali rappresentazioni dovrebbe essere sotto forma di una base di regole (insieme di attributi di dati e sconto risultante contro di esso) e la funzione come sopra lo ripeterebbe per calcolarlo. Se le regole vengono aggiunte o rimosse non dovresti finire per cambiare il codice, basta cambiare la rule base.

Il modello sarà richiesto solo se abbiamo bisogno di oggetti diversi per 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 li modifica) - quale modello di progettazione utilizza? La risposta è NESSUNO di quanto sopra descritto!