These are two classes, the first one I inject an instance of type IEngine while the second one I inject owner's name, tickets and engine.Version 1:  public class Car{    public Car(IEngine engine)    {        // do something here    }    public void PrintOwnerName()    {    }}Version 2:public class Car{    // owner's name, tickets history of this car, and the engine.    public Car(string ownerName, List<string> tickets, IEngine engine)    {    }    public void PrintOwnerName()    {    }}I was wondering if the version 2 is bad design. If so, why is it bad?
Is it bad to use DI to inject constructor parameters at runtime?
design;design patterns;dependency injection
The decision which parameters a constructor should have is the same decision which parameters an arbitrary function should have - it should have exactly the parameters which are needed to create a specific, ideally easy to understand, abstraction. And if your abstraction of a car encapsulates exactly those three things, version 2 reflects that much better than version 1.In your first version, you would have to provide owner name and tickets differently, probably by setting those properties afterwards. But if those properties must be always provided, it is IMHO a better design enforce this by constructor parameters.One thing you have to care for is that the number of parameters passed through the constructor does not grow to a point where the code becomes hard to understand. For example, when you have a lot more parameters for your car like vendor, color, number of seats, number of doors, list of previous owners, needed driving licence for this type of car, and so on, then you should obviously not pass them all through the constructor (at least, not one by one). One approach to handle this can be to introduce one or more service facades. Another approach might be to add some properties (for things which are optional or might be changed later, as described in @Stephen's answer).To make decision which is the best solution, however, one has to look at the actual parameters and their meaning, you cannot make a good decision just on number and types of the parameters. I assume your car example is just a placeholder for something different in your real program, for which the situation might be different, but to discuss it in terms of a car: the owner's name is typically a property of the owner, not of the car, and the list of tickets is AFAIK something associated with the owner, too. So you might consider to introduce an Owner class for this example, where the owner has a name and a list of tickets. So this leads to a constructor public Car(Owner owner, IEngine engine)However, taking Stephen's advice into account, assuming the owner of a car can change over the lifetime of a car object, it might be indeed better to stick to your original version 1, provide a getter and a setter for the current owner and implement your PrintOwnerName() function with regards to the fact that the owner of the car might be unknown (which means uninitialized).