Revisione di progetto di un piccolo quadro di configurazione [chiuso]

Question

Revisione di progetto di un piccolo quadro di configurazione [chiuso]

#1 da (0 voti)
#2 da (0 voti)

3

Voglio creare un semplice framework di configurazione . Sì, lo so, ci sono molti quadri che rendono il loro lavoro molto bene. Ma per l'architettura interessante, voglio creare il mio.

Il mio framework dovrebbe notare i principi di SOLID Dovresti essere in grado, per memorizzare la configurazione in diversi formati. Come prova del concetto, ho disegnato un semplice uml.

Tutto inizia con un semplice factory . Questo factory restituisce una classe astratta chiamata: " Configurator ". All'interno della classe " Configurator " c'è un factory di metodi, che restituisce un'interfaccia, chiamata: " IConfigurationSource ". L'origine della configurazione è solo un'interfaccia per la memorizzazione delle mie impostazioni in un file o in qualsiasi altra memoria di dati.

Solo un esempio di implementazione xml:

Per un nuovo formato, devo creare una nuova classe che erediti " Configurator" . Devi sovrascrivere il metodo factory e restituire un tipo concreto di " IConfigurationSource ". In questa classe, " IConfigurationSource " sarà inizializzato. Devo anche implementare una classe che eredita di nuovo " IConfigurationSource ". Questa classe fornirà la mia gestione dei dati in una concreta archiviazione dei dati, nel nostro esempio un file xml.

Almeno, una breve descrizione delle mie variabili (esempi):

: per ogni componente di configurazione, fornirò un file xml separato. Ciò significa: "registrazione, rete, utenti, ecc."
valueName: questo è il nome di un elemento di configurazione. Ad esempio: "maxUsersAtTheSameTime"
valore: questo è il valore stesso

Questa è la mia idea, per creare un semplice framework di configurazione. Più tardi implementerò qualcosa come mappatura degli oggetti, ecc ...

Questo progetto supporta pienamente i principi SOLID?

design architecture design-patterns frameworks solid

posta Marcel Hoffmann 16.11.2015 - 16:35

fonte

2 risposte

Leggi altre domande sui tag design architecture design-patterns frameworks solid

Assembler vs Entity Translator ed Entities vs DTO ng-model per l'elenco di selezione dello stato [chiuso]

score 0 · Answer 1

Bene, tutto ciò che hai descritto è troppo astratto per ragionare davvero, ma ci proverò.

Credo che tu abbia il seguente problema. La classe di Configurator sembra una memoria di configurazione in memoria, a cui l'applicazione leggerà / scriverà. Ma perché legarlo ad alcune classi concrete creando due istanze di classi parallele?

Quando parli di configurazione, hai due chiare responsabilità:

Memoria della memoria in memoria valore-chiave (può essere, ad albero) per applicazione per leggere / scrivere su.
Vari lettori di configurazione e scrittori per salvare / caricare la configurazione da vari formati di file.

Nel tuo caso leghi entrambe le gerarchie di classi (Configurator e ConfigurationSource) al formato di file e credo che questo sia eccessivo. La memoria di configurazione in memoria dovrebbe essere indipendente dal formato.

Tale design rende anche focalizzato il tuo formato di file di fabbrica perché dovrebbe creare fonti di configurazione solo, ad esempio, l'url delle risorse per caricare la configurazione (beh, estrai qualcosa un po '). Nessun configuratore specifico necessario qui.

score 0 · Answer 2

Questo è un buon esercizio e mi piace il processo di pensiero su cui ti trovi.

Ecco la mia recensione di questo design.

Principio di responsabilità singola

È chiaro che ogni classe è responsabile di una singola cosa.

Principi aperti-chiusi

Non penso che questo sia soddisfatto poiché la fabbrica cambierà quando verrà introdotto un nuovo formato. La fabbrica non ha bisogno di essere accoppiata all'insieme dei formati disponibili nella mia mente. L'individuazione del servizio o l'iniezione di dipendenza potrebbe colmare questa lacuna.

Principio di sostituzione di Liskov

Spot on. Esistono classi di implementazione singole (contrassegnarle come finali) che implementano direttamente le interfacce. La mancanza di una gerarchia profonda rende LSP facile da raggiungere.

Principio di inversione delle dipendenze

Cade qui sotto come la ConfigurationFactory conosce sia Configurator , l'interfaccia e XmlConfigurator , l'implementazione. La distinzione tra Configurazione e IConfigurationSource sembra essere una partizione priva di significato senza ulteriore contesto. Il diagramma non mostra ad esempio altri usi di Configurator , quindi non c'è alcun vantaggio evidente nell'interfaccia se la fabbrica deve comunque conoscere le implementazioni concrete.

Questo potrebbe essere risolto facendo in modo che la fabbrica carichi le implementazioni tramite l'individuazione del servizio dell'iniezione delle dipendenze. Nel caso dell'iniezione di dipendenza, la fabbrica verrebbe ottenuta da un iniettore e le varie associazioni di classi concrete si troverebbero in un modulo.

Conclusione

Nel complesso, penso che tu sia molto vicino a SOLID con questo design.