CODEWITHSUNDEEP
c#class
James Wood
James Wood

Reputation: 17562

How many constructors is too many?

I am currently working on a class which represents one thing. That one thing can have multiple representations. The representation for any given instance of that thing is fixed when constructed. Depending on which representation is being used depends on what data is being stored.

For (an abstracted) example:

This has led me to have one class with three specialised constructors, for example:

public enum RepresentationType { Alpha, Beta, Charlie }

public class Representation
{
    ...
    public Representation(Guid id, String name) { Type = RepresentationType.Alpha, ... }
    public Representation(Guid id, String name, String attributes) { Type = RepresentationType.Beta, ... }
    public Representation(Guid id, String name, Guid childId) { Type = RepresentationType.Charlie, ... }
}

I can see why I've ended up here, and in some ways this approach makes sense; the class represents a single type of thing, and it has a lot of shared functionality.

However its also problematic for a number of other reasons:

I'm considering refactoring this all into a set of sub classes, e.g. RepresentationAlpha, RepresentationBeta, RepresentationCharlie. This means I'll have to write some more code, but nothing too onerous. I can see problems further down the line however when I need to work with a representation from a collection and I don't know which representation I'm actually looking at.

Is this a sensible course of action? Am I just trading one problem for another? Is there a design pattern I should be looking at? How many constructors is too many?

Edits based on comments:

Upvotes: 1

Views: 583

Answers (2)

Jon Hanna
Jon Hanna

Reputation: 113292

There's a strong advantage in having no more than one constructor.

Once you've lost the advantage in having two, there's diminishing down-sides to each. Having half a dozen or more is not unusual for some sorts of classes where each overload can be clearly justified.

I've attempted to improve this by chaining constructors but then I'm ending up with long chains of functions.

This isn't such a bad thing, as each step of the chain should be obvious enough considered in isolation. If it isn't, then that's a sign of a bigger problem, which may suggest that it isn't so much a matter of two many constructors, as too few classes, and they should be separated out into different classes entirely (though perhaps sharing a common base or implementing a common interface).

Upvotes: 1

Alexei Levenkov
Alexei Levenkov

Reputation: 100547

There is nothing really wrong with several constructors. If class actually represent "one thing" having single class makes sense.

To avoid non-initialized fields consider shared (maybe private) constructor that will be called from all of your other constructors to initialize common fields.

Inheritance often lead to more problems than it worth (i.e. if JSON serialization is involved), so I'd wait till you must have it and only at that point consider adding inheritance.

On other hand if "one thing" is just loosely defined and types have vastly different in behavior - try inheritance, but also see if common interface for non-related classes would work.

Upvotes: 1

Related Questions