Giving a class many constructors and assigning via them as many properties as possible

Question

I have written a class which represents a SQLite Trigger.

    public SQLiteTrigger(string Name, 
                         string On, 
                         TriggerStartType StartType, 
                         TriggerEventType EventType) : this(...)

    public SQLiteTrigger(string Name, 
                         string On, 
                         TriggerStartType StartType,  
                         TriggerEventType EventType, 
                         string TriggerSQL) : this(...)

    public SQLiteTrigger(string Name, 
                         string On, 
                         TriggerStartType StartType, 
                         TriggerEventType EventType, 
                         string TriggerSQL, 
                         string When)

I'm thinking about adding even more constructors with more parameters, so nearly every Trigger creation could be a one liner. Is it against any design rules or considered as bad practice when you give a class many constructors and assign via them as many properties as possible?

This is a great idea @svick. I think ill use these. But this still doens't awnser if it is bad style. — SmallestUncomputableNumber, Apr 24 '16 at 18:37
Possible duplicate of [Constructor with tons of parameters vs builder pattern](https://softwareengineering.stackexchange.com/questions/311297/constructor-with-tons-of-parameters-vs-builder-pattern) — gnat, Apr 18 '18 at 10:08

candied_orange · Accepted Answer · 2022-12-10T20:52:51.180

Excuse me while I react to everyone suggesting the builder pattern here:

This is C#, not Java!

A main reason for Joshua Bloch's builder pattern is to hack around Java's lack of named arguments. This gives Java a way around the evil telescoping constructor pattern.

You're in C#. You have named arguments!

Another reason for Joshua Bloch's builder pattern is to separate required arguments from optional arguments (those that have a good default value) and allow any combination of optional arguments to be set. This is needed because Java doesn't natively support optional arguments.

You're in C#. You have optional arguments!

That means the 3 constructors you've listed should be replaced with just 1:

public SQLiteTrigger(
    string Name, 
    string On, 
    TriggerStartType StartType, 
    TriggerEventType EventType, 
    string TriggerSQL = "some default string", 
    string When = "some other default string"
)

And now, unlike before, clients can change When without fiddling with TriggerSQL.

new SQLiteTrigger(
    Name: "MyTrigger", 
    On: "Whatever", 
    StartType: new TriggerStartType(),
    EventType: new TriggerEventType(),
    When: "Now"
)

Compared to the Bloch builder this is

Easier for clients (humans) to use
Easier to implement
A flexible design

Don't get me wrong, I love the Bloch builder. In Java. Don't use hacky workarounds in languages that don't need them.

Now you asked about good style and you mentioned adding more parameters. Be careful of adding too many. This is called arity. Too much arity is a code smell that may indicate a flaw in your underlying design. There are ways to redesign to reduce airity.

If those additional parameters are more complicated than the simple required vs. optional (with a good known default) pattern then you might be interested in the next step beyond the Bloch builder. The DSL builder.

Great answer. Thanks for the additional information provided — SmallestUncomputableNumber, Apr 25 '16 at 08:00

score 1 · Answer 2 · answered Dec 09 '22 at 20:49

As an alternative you can use factory methods. The factory methods may give more meaning to what you are initialising.

This might be a signal that you are violating the single resposibility principle.
Perhaps composing the object of some parts improves the design. Or you might be served by a hierachy defining the different kinds of object you are creating. The strategy pattern might help as well.

Time has caught up on us. In C# you can now use init only properties and records, these might help as well in this sotuation.

score 0 · Answer 3 · answered Apr 22 '16 at 15:51

Is it against any design rules or considered as bad practice when you give a class many constructors and assign via them as many properties as possible?

This sounds like:

you need a builder pattern. Implement a builder, and you can then call 'build()' repeatedly on a previously constructed builder, adjust parameters as required
if you have that many properties, does your class need decomposing into more classes, each having a specific well-defined responsibility ? If your class has so many properties, I would start to question if it alone is doing too much

Thank you for your answer. To point 2: In fact it just represents a single SQLite-Trigger, so I dont think it should be splittet into more classes. All properties are simply properties of a SQLite-Trigger. — SmallestUncomputableNumber, Apr 22 '16 at 21:47

score -1 · Answer 4 · answered Apr 25 '16 at 01:00

Is it against any design rules or considered as bad practice when you give a class many constructors and assign via them as many properties as possible?

I don't think is a bad practice to do that, but I think the real question here is: Are you sure they are really needed? There is the YAGNI (You Aren’t Gonna Need It) principle of software development that might apply here in you case, you need to do only what you really need and stop thinking that this or that might be useful in the future.

I invite you to read this little article I wrote some time ago that might help you a little bit to take the decision on your own: KISS, YAGNI & DRY, 3 Principles to Simplify Your Life as Developer

Giving a class many constructors and assigning via them as many properties as possible

4 Answers4

Linked