Dilemma di selezione del modello di progettazione

Question

Il controllore riceve un elenco di diversi tipi di frutta dall'utente. Il controllore deve fare il succo da ognuno di questi frutti. Uno spremiagrumi può produrre succo di arancia e pompelmo; un altro spremiagrumi sa fare il succo di mela, banana e papaia; e così via. Ogni spremiagrumi può accettare più frutti in una volta sola, elabora solo i frutti di cui è capace e ignora gli altri frutti non toccati. Si prega di suggerire un design appropriato per questo problema. Ho preso in considerazione le seguenti opzioni:

1. controller chiama MasterJuicer.juice(List<Fruit> fruits). MasterJuicer a sua volta chiama CitrusJuicer.juice(fruits) e PulpyJuicer.juice(fruits).
2. La catena di responsabilità non sembra giusta. L'ordine in cui vengono chiamati gli spremiagrumi non ha importanza.
3. Fabbrica? Controller chiama JuicerFactory.getJuicers(List<Fruit> fruits) per ottenere un List<Juicer>. Il controller quindi scorre attraverso ogni spremiagrumi e chiama Juicer.juice(fruits). È comune per una fabbrica restituire un elenco di istanze?
4. Mantenere un registro di Fruit vs. Juicer in un Map? Il controller chiama FruitsRegistry.getJuicer(Fruit fruit) per ogni frutto, quindi chiama ogni spremiagrumi in un ciclo.

Answer 1

Una fabbrica può fornire gli spremiagrumi corretti, ma la logica di gestione degli spremiagrumi viene quindi inviata al controller.

A combination dei modelli composite e visitor potrebbero essere utili.

1. Il composite vi permetterà di costruire un MasterJuicer che conosce le altre centrifughe e può iniziare il "processo di spremitura" delegando alle centrifughe. Questo gestisce l'aspetto "strutturale" del tuo problema.
2. Il pattern visitatore consente a ciascun juicer di disporre di un metodo uniforme per interagire con essi senza che il chiamante (il MasterJuicer composito) si preoccupi di come lavorano insieme. Questo gestisce l'aspetto "comportamentale".

È possibile passare un elenco di ingredienti da elaborare tra ciascun visitatore in modo che possano interagire con i frutti di cui si occupano.

Se non si desidera registrare manualmente i propri spremiagrumi con il MasterJuicer, è consigliabile acquisire familiarità con qualche tipo di rilevamento dei servizi.Una tecnica comune in Java consiste nell'utilizzare le annotazioni e la scansione del classpath per trovare le classi in fase di runtime e registrarle automaticamente all'avvio. Ci sono a few libraries disponibili che fanno questo, o se stai già usando il Framework di Primavera puoi usare il suo built-in scanning tools.

Answer 2

penso che la terza opzione è la più appropriata, anche se il fabbrica dovrebbe essere responsabile per la restituzione del spremiagrumi appropriati per il compito - in modo che non deve restituire tutte le centrifughe, ma quello che vi serve per l'attività. La Mappa può essere inclusa per aiutare la scelta giusta.

questo caso il fabbrica contiene la logica per la scelta del spremiagrumi destra, non il controller.

Answer 3

vi consiglio di Decorator Pattern

L'idea principale è che avete uno spremiagrumi base e lo si aggiunge altre funzionalità.

Spero che aiuti!

Answer 4

A mio parere il modello il vostro ricerca è la catena di responsabilità

http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern

riguarda

Answer 5

Questo è sicuramente una catena di responsabilità. In qualche modo, itera su Juicers e crea il succo finché non hai finito la frutta. Alcune cose da considerare è la necessità di mescolare i succhi risultanti (probabilmente un modello composito su Juice) e come organizzare la precedenza (se due spremiagrumi spremeranno il pompelmo, che dovrebbe arrivare a farlo?). Incapsula tutta questa logica dietro l'interfaccia Juicer.