Miglior modello di progettazione per un sistema di prenotazione condizionale

Question

Sto costruendo un sistema di prenotazione di voli da una specifica per la mia classe OOP al college. Il sistema deve essere scritto in C#. Mi chiedo quale sia il modo migliore per affrontare il seguente problema:

Attualmente la società gestisce uno sconto. I residenti di Western Isles ottengono uno sconto del 10%. Scotia registra anche l'isola di residenza di questi passeggeri per scopi di marketing. I viaggiatori d'affari hanno uno sconto del 25% e devono fornire il nome della propria azienda. I passeggeri ordinari non ricevono lo sconto , a meno che non facciano parte di una promozione in corso, nel qual caso ricevono uno sconto del 5% .

Devo avere una classe passeggeri, da cui ogni tipo di cliente separato eredita? Qualsiasi aiuto su questo sarebbe apprezzato

Answer 1

A mio parere è non desidera ereditare da Passeggero. L'ereditarietà implica che l'oggetto cambi in qualche modo, ma un passeggero è un passeggero indipendentemente dallo sconto che ottiene. In altre parole, la sua funzionalità non cambia solo perché ottiene uno sconto maggiore.

Questo esempio che si utilizza è molto simile agli esempi generalmente forniti per il modello Decorator, sebbene ciò avvenga solitamente perché dimostra che più sconti possono essere applicati all'oggetto da decorare (Passeggero nel tuo caso). Date un'occhiata a l'esempio di caffè sulla wiki here

Un'altra possibilità è Strategy modello, questo ti dà un'interfaccia pulita per la creazione di un biglietto per un passeggero, mentre internamente commuta il DiscountStrategy seconda di quale tipo di passeggero sta richiedendo un biglietto .

Answer 2

se si tratta di sconti, potrebbe essere sufficiente utilizzare solo il modello decoratore come descritto da altri.

Quindi si dovrebbe verificare il tipo di interfaccia e non del passeggero, se si desidera ad es. elenca il numero di viaggiatori d'affari o di residenza per scopi di marketing ecc.

Answer 3

Vuoi rendere flessibile la politica di sconti, i passeggeri non sono poi così diversi.

È possibile avere una classe base e Company, ma ciò non influisce in realtà sulla modalità di applicazione della logica di sconto.

L'ereditarietà implica un comportamento diverso, ma il comportamento dei passeggeri non cambia, solo gli sconti applicati e lo sconto non devono far parte dello stato passeggeri, quindi non rientrano in tale classe. Inoltre, molti sconti sono attivi solo per un intervallo di tempo, e non ha senso codificarlo nella classe Cliente, dovresti essere in grado di aggiungerli e rimuoverli in modo dinamico.

Poiché la logica di sconto è in realtà una regola aziendale applicata al cliente, deve essere incapsulata in un insieme separato di classi. Lo schema comune utilizzato per implementare questo è strategy. A seconda del modello, poiché si desidera applicare criteri diversi a tipi diversi di utenti, è possibile che il modello visitor sia utile o meno.

Answer 4

Vorrei utilizzare un modello di strategia come descritto nei post precedenti "Un'altra possibilità è il modello di strategia, questo offre un'interfaccia pulita per la creazione di un biglietto per un passeggero, mentre internamente passa a DiscountStrategy a seconda del tipo di passeggero che richiede un biglietto."