Iniezione, strategie e OO

Question

Iniezione, strategie e OO

#1 da (2 voti)

2

Sto lavorando al refactoring di un progetto. La logica aziendale sembra molto simile all'utilizzo del modello di strategia sarebbe molto utile, perché in base ai valori di tre proprietà (diciamo età, sesso e stipendio), viene applicata una politica di sconto e di convalida diversa.

La mia prima idea è stata quella di mettere la logica responsabile per decidere quale politica applicare in StrategyFactory, e fare in modo che restituisca un'implementazione diversa dell'interfaccia di una strategia. La mia preoccupazione è legata a dove e dove non usare DI. StrategyFactory richiederà alcuni DI per chiamare altri servizi, così come alcuni, ma non tutti gli oggetti della strategia.

Quindi alla fine, devo annotare quasi tutto come un @ Service / @ Component o fare in modo che la Factory invii i servizi alle strategie tramite parametro, cosa che sembra ancora peggio.

Mi manca qualcosa o è normale? Potrebbe essere che i livelli dell'applicazione siano troppo aggrovigliati? Non è questo il caso / modo giusto per usare il modello di strategia?

Ho solo bisogno di una breve risposta se c'è qualcosa che suona molto chiaramente sbagliato.

object-oriented dependency-injection design-patterns spring strategy

posta user3748908 11.06.2015 - 11:07

fonte

1 risposta

Leggi altre domande sui tag object-oriented dependency-injection design-patterns spring strategy

Esiste un modo per rendere il modo predefinito in cui una classe accede a un campo all'interno della classe? È sicuro accedere direttamente a superglobali con isset ()?

score 2 · Accepted Answer

Nel modello strategico originale una strategia viene iniettata nel consumatore. Il codice che crea sia il consumatore sia la strategia è responsabile della scelta della strategia appropriata. È più semplice, quindi se puoi, dovresti attenersi a questo approccio.

Tuttavia, il problema non è insolito: la strategia deve essere scelta in runtime in base ai parametri di input. Vedo qui due aspetti:

creazione di strategie
scegliere la strategia appropriata in base ai parametri

Il primo è un dettaglio tecnico e il secondo è solitamente una regola logica dell'applicazione. Entrambi gli aspetti dovrebbero essere separati (vedi Principio di responsabilità singola ).

È perfettamente corretto delegare la creazione di oggetti (comprese le strategie) al framework Iniezione delle dipendenze (ad esempio usando le annotazioni Spring @Component , anche se preferisco Configurazione basata su Java che separa ulteriormente la creazione di oggetti e la logica dell'applicazione.

Il secondo aspetto, scegliendo una strategia, può essere implementato in una classe separata, come StrategyChooser . Tale classe può anche essere creata dal framework DI e possono essere iniettate strategie specifiche. Sulla base dei parametri, la classe può decidere quale strategia utilizzare. Non chiamerei questa classe Factory in quanto Factory pattern riguarda la creazione di oggetti, che non è il caso qui.