Configurazione algoritmo incapsulamento nella gerarchia di sistema [chiusa]

Question

Configurazione algoritmo incapsulamento nella gerarchia di sistema [chiusa]

#1 da (0 voti)

1

Dire, sto costruendo un sistema che usa vari algoritmi complessi (k significa, spostamento medio, pochi altri), tutti parametrizzati. Sto evidenziando 'usi', perché il sistema non è solo un sottile strato attorno a loro; nel profondo della sua elaborazione, questi algoritmi sono istanziati ed eseguiti.

Le parti "stupide" del sistema non hanno bisogno e non dovrebbero conoscere i parametri specifici richiesti da questi algoritmi, ma in qualche modo questi algoritmi devono ottenere i loro parametri da una configurazione centrale.

Quali sono le buone strategie per determinare l'origine della configurazione a livello di sistema, ma evitare di passare i singoli parametri attraverso diversi livelli del software dove sono necessari?

Penso che sia la magia dell'iniezione di dipendenza o un oggetto di configurazione non specifico (ad esempio una mappa) che viene passato in giro. Il primo sembra un po 'una grande responsabilità per un compito così banale, il secondo non elimina completamente la necessità di avere parametri gestiti da codice che non dovrebbe riguardarli.

design configuration configuration-management

posta Johannes Bauer 10.12.2015 - 13:38

fonte

1 risposta

Leggi altre domande sui tag design configuration configuration-management

Seleziona la sequenza per minimizzare il costo Attribuzione del codice a un post che cita una fonte originale [chiuso]

score 0 · Answer 1

Il modo in cui ho gestito questo nei miei progetti è che, prima di tutto, mantengo sempre una chiara distinzione tra ciò che è un codice specifico per l'applicazione (specifico del dominio) e ciò che è un codice generico. I tuoi algoritmi possono essere pensati, suppongo, come codice generico.

La configurazione viene caricata dalla classe dell'applicazione radice (l'oggetto 'applicazione') e archiviata in una struttura specifica dell'applicazione. Questa non è una mappa generica, è una struttura reale con campi singoli strongmente tipizzati, con nomi lunghi che spiegano con precisione cosa rappresenta ciascun valore. Tutto il codice specifico dell'applicazione ha generalmente un riferimento all'oggetto dell'applicazione, quindi è libero di ottenere questa struttura da esso.

L'applicazione può essere costituita da sottosistemi o moduli. Ogni modulo può essere pensato a sua volta come un'altra applicazione, con una propria struttura di configurazione, che di solito contiene un sottoinsieme dei campi della struttura di configurazione dell'applicazione principale. Per ogni modulo, sono lieto di passare i campi pertinenti della struttura dell'applicazione principale in modo che possano essere memorizzati nei campi della struttura di configurazione del sottosistema. Fortunatamente, il numero di sottosistemi non è così grande, quindi questo non rappresenta un grosso problema.

Nel momento in cui vado oltre il confine tra codice specifico dell'applicazione e codice generico, passo sempre ogni singolo valore come parametro distinto, strongmente tipizzato, opportunamente chiamato a ogni singolo metodo o costruttore che ne ha bisogno, e da in quel momento subirò volentieri il dolore di propagare questi parametri con tutti i livelli profondi necessari.

È vero, questi parametri sono spesso alterati, (alcuni vengono aggiunti, alcuni sono abbandonati, cambiano nomi o tipi, ecc.) quindi c'è un po 'di digitazione, ma il nostro collo di bottiglia principale nella nostra professione non è la digitazione; è gestione della complessità. Che richiede chiarezza. Quindi, questo meccanismo paga.