Principi SOLID e generazione di molti oggetti da un file

Question

Principi SOLID e generazione di molti oggetti da un file

#1 da (4 voti)
#2 da (3 voti)
#3 da (2 voti)

1

La "D" in SOLID sta per inversione di dipendenza. Ad esempio, se una classe Blacksmith dipende da Hammer , dovrei creare esternamente il mio Hammer e passarlo a Blacksmith , piuttosto che avere Blacksmith creare il proprio Hammer . Questo mi rende più facile dare il mio Blacksmith a DeluxeMagicHammer senza dover modificare il suo comportamento.

Questo ha senso quando le mie dipendenze sono definite e istanziate nel codice. Ma cosa succede se le mie dipendenze sono definite nei dati, ad esempio in uno schema JSON o XML? Vorrei passare war-cart-blueprints.xml al mio Blacksmith e farle leggere e utilizzare tali informazioni per creare il 4% diWheel s, il 2% diAxle s, un% diCabin, ecc. E metterle insieme in un %codice%. Sembra che ora sto creando un accoppiamento stretto tra WarCart e questi vari componenti.

Per soddisfare SOLID, devo separare queste dipendenze in qualche modo? Avrei bisogno di un Blacksmith , WheelFactory e AxleFactory , ognuno dei quali guarda lo stesso CabinFactory per costruire i componenti di cui sono responsabili, e poi li passa a war-cart-blueprints.xml per l'assemblaggio? Cosa succede se ci sono alcune dipendenze tra Blacksmith e WheelFactory , tali che avrebbero bisogno di comunicare per portare a termine le loro rispettive attività? Ad esempio, AxleFactory potrebbe avere un diametro del foro centrale, ma i blueprints specificano solo quel diametro nelle specifiche Wheels . Oppure, le dimensioni di Axle sono determinate da un calcolo complesso basato sulla lunghezza di Cabin s e il numero di Axle s.

Sembra che sarebbe molto più semplice lasciare Wheel creare e assemblare i componenti lei stessa, specialmente se è l'unica che li userà mai.

dependency-injection solid factory schema separation-of-concerns

posta alexw 03.04.2016 - 23:25

fonte

3 risposte

Leggi altre domande sui tag dependency-injection solid factory schema separation-of-concerns

Includere entrambe le versioni "attenta" e "pericolosa" di una funzione in una libreria / modulo Come denominare le funzioni che utilizzano i condizionali nel refactoring [chiuso]

score 4 · Answer 1

Se porto un martello al mio fabbro, ciò significa che il fabbro non ha bisogno di conoscere i dettagli più fini di quale martello ottenere; Ho solo bisogno di dargli il martello più appropriato per il mio lavoro previsto.

Non importa se le tue dipendenze sono nel codice o nei dati. Con ogni probabilità, se le tue dipendenze sono nei dati, rappresentano comunque informazioni di configurazione per oggetti che hai intenzione di consegnare al fabbro tramite DI comunque.

La vera differenza tra i due scenari è che le dipendenze sono molto più complesse nello scenario automobilistico. Per questo motivo è più probabile che tu dia al "fabbro" una Fabbrica astratta o una collezione di parti di automobili.

score 3 · Answer 2

Le domande da porre nella progettazione:

What information does Blacksmith need when they are "building" an object?

How do the different things a blacksmith can make affect the behaviour of Blacksmith?

Blacksmith ha bisogno di conoscere dettagli come assi e ruote? O ha solo bisogno di sapere che sta costruendo un WarCart e richiederà 7 iron e 3 wood , e prenderà 4 days con uno Hammer standard.

Quindi - WarCart è un oggetto Buildable - ha componenti (che sono anche Buildable ) come ruote e assi che hanno entrambi costi materiali e di tempo. Ora tutto ciò che Blacksmith deve fare è chiedere all'interfaccia Buildable di WarCart la quantità di materiale e tempo necessari con metodi come cost() e time() .

Avrei quindi un BuildableFactory che accetta la configurazione per l'oggetto che si sta costruendo e i suoi componenti e genera WarCart o Trebuchet o qualsiasi altra cosa.

Quindi, i vari fabbri possono chiamare il BuildableFactory ogni volta che si desidera aggiungere un oggetto costruibile nelle loro code di costruzione.

score 2 · Answer 3

Hai appena colpito uno dei problemi più sfumati con SOLID. Che aumenta notevolmente la complessità della tua applicazione. In particolare iniezione di dipendenza. Ma ottieni molta più flessibilità con il tuo codice per quella complessità.

Quindi spetta a te utilizzare la tua esperienza e competenza come sviluppatore di software: il miglioramento della flessibilità del codice merita l'aumento della complessità? Questa è una domanda estremamente difficile da rispondere e per la quale non esistono "schemi" o "principi". E non saremo in grado di aiutarti a meno che non conosciamo e comprendiamo appieno TUTTI i requisiti che hai e comprendiamo il tuo dominio in modo da poter prevedere almeno in qualche modo le modifiche a tali requisiti.