2

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?

4
16

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 to 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.

1
0

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:

  1. you need a builder pattern. Implement a builder, and you can then call 'build()' repeatedly on a previously constructed builder, adjust parameters as required
  2. 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
1
  • 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
0

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.