È una cattiva pratica semplificare le dipendenze del costruttore usando un semplice contenitore quando la classe rappresenta il punto di ingresso per un sottosistema?

0

Ho un sistema che dipende dalle transazioni e da altre cose. Questa lista può diventare molto lunga. Le transazioni possono essere (e saranno) implementate in due o più modi, quindi ogni transazione è un'interfaccia.

public class System
{
    ctor(ITransactionA a, ITransactionB b, ... ITransactionN n, ...)
}

Nel mio strumento DI, registro quale implementazione di ITransaction voglio utilizzare.

Voglio semplificare il costruttore.

Un'opzione è usare le fabbriche. Ma poi ho un sacco di codice extra e ho bisogno di fornire un qualche modo per scegliere quale ITransaction usare. Non ho il tempo o il potere dell'uomo per mantenere il codice extra. La scelta giusta è registrare comunque le ITransactions nello strumento DI: la radice è il posto giusto per prendere questa decisione. Il sistema non dovrebbe scegliere quale implementazione usare, e se usassi le fabbriche astratte finirei con quante sono le modalità per definire le n transazioni.

In questo caso, è una cattiva pratica (ovvero, questa tecnica causerà problemi di progettazione) la creazione di un mini-contenitore per semplificazione del costruttore?

public class ConcreteTransactionsContainer
{
    public ITransactionA {get;}
    public ITransactionB {get;}
    ...
    public ITransactionN {get;}

    ctor(ITransactionA a, ITransactionB b, ... ITransactionN n)
}

public class System
{
    ctor(ConcreteTransactionContainer trxs, IOtherThing other, IAnother, another)
}

In questo modo, controllo quale implementazione fornire nello strumento DI, ma il codice importante, in cui chiunque deve mantenere il codice, è semplice e facile da seguire, senza il sovraccarico di un complesso insieme di fabbriche.

O mi sto tormentando troppo per il lungo costruttore? Odio davvero le firme dei costruttori lunghi.

    
posta Price Jones 12.05.2016 - 17:37
fonte

1 risposta

1

In this case, is it bad practice (that is, will this technique cause any engineering problems)

A livello tecnico, nessun problema. In pratica stai aggiungendo un livello all'interno del grafico delle dipendenze per ridurre la quantità di ramificazione che sta succedendo. Non dovrebbe causare problemi tecnici. (Se è davvero importante per la velocità di istanziazione, qualcosa è già andato molto male.)

La vera sfida coinvolge concetti e comunicazione: se possibile, vuoi creare un nome per il tuo ConcreteTransactionsContainer che ti faccia davvero sentire come se avessi acquisito un importante concetto nel tuo sistema, qualcosa che in precedenza era solo implicito.

Esiste qualcosa che definisce / descrive la raccolta in fase di progettazione di oggetti Transaction oltre "il mio System capita di averne bisogno"? Ci saranno mai "fratelli" in System che richiedono un sottoinsieme diverso della collezione-transazione?

    
risposta data 12.05.2016 - 18:12
fonte

Leggi altre domande sui tag