I have a System which depends on Transactions, and a few other things. This list can become very long. Transactions can be (and will be) implemented in two ways or more, so every transaction is an interface.public class System{    ctor(ITransactionA a, ITransactionB b, ... ITransactionN n, ...)}In my DI tool, I register which implementation of ITransaction I want to use. I want to simplify the constructor. One option is to use factories. But then I have a ton of extra code and I need to supply some kind of way to choose which ITransaction to use. I don't have the time or the man power to maintain the extra code. The right choice is to register the ITransactions into the DI tool anyway - the root is the right place to make this decision. The System should not be choosing which implementation to use, and if I used abstract factories I would end up with as many as there are ways to define the n transactions.In this case, is it bad practice (that is, will this technique cause any engineering problems) to create a mini-container for the sake of constructor simplification?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)}This way, I control which implementation to provide in the DI tool, but the important code, where anyone who has to maintain code will be, is simple and easy to follow, without the overhead of a complex set of factories.  Or am I agonizing too much over the long constructor? I really hate long constructor signatures. 
Is it bad practice to simplify constructor dependencies using a simple container when the class represents the entry point for a sub system?
design;design patterns;constructors
In this case, is it bad practice (that is, will this technique cause any engineering problems)On a technical level, no problem. You're basically adding a layer inside the dependency graph in order to reduce how much branching is going on. It shouldn't cause any technical problems. (If it actually matters for instantiation-speed, something has already gone very wrong.)The real challenge involves concepts and communication: If possible, you want to come up with a name for your ConcreteTransactionsContainer that really makes you feel like you've captured an important concept in your overall system, something which was previously just implicit.Is there something that defines/describes that design-time collection of Transaction objects beyond my System happens to need them? Are there ever going to be siblings to System that require a different subset of the transaction-collection?