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.