Is it bad form to provide excessive overloads for a method or constructor in C#?

Question

I am writing code for Unity, using C#. At present, I am dealing with a few smaller classes and structures, in effort to quickly serialise a randomly generated map. In doing so, I deal with a few constructors that also take some of these smaller classes and structures, as parameters.

In the past, I would typically try to consider the plausible options when setting up my methods and constructors. While this practice has been questioned, no-one has managed to give me any plausible reason as to why I shouldn't do it in this way.

---

Consider the following class and structures:

public class Tile
{
    public GridCoordinates position;
    public TileCode prefabID;
}

public struct GridCoordinates
{
    public int x;
    public int y;
}

public struct TileCode
{
    public int categoryID;
    public int individuaID;
}

Typically, I would cover all struct and int alternatives, when creating the constructors. Tile would look something like this:

public class Tile
{
    public GridCoordinates position;
    public TileCode prefabID;

    public Tile(TileCode prefabID, GridCoordinates position)
    {
        this.prefabID = new TileCode(prefabID);
        this.position = new GridCoordinates(position);
    }

    public Tile(TileCode prefabID, int xPosition, int yPosition)
    {
        this.prefabID = new TileCode(prefabID);
        position = new GridCoordinates(xPosition, yPosition);
    }

    public Tile(int typeID, int individualID, GridCoordinates position)
    {
        prefabID = new TileCode(typeID, individualID);
        this.position = new GridCoordinates(position);
    }

    public Tile(int typeID, int individualID, int xPosition, int yPosition)
    {
        prefabID = new TileCode(typeID, individualID);
        position = new GridCoordinates(xPosition, yPosition);
    }

---

I tend to do this for efficiency. It takes me an insignificant amount of excess time to write the additional constructors/methods in tandem with the first constructor/method, and I find this sometimes comes in handy when I later wish to use the constructor/method in a way I had not originally anticipated.

The only issue that has been raised, previously, is the potential for confusion. I feel this is not really an issue, as my organisation and comments clearly distinguishes each variation.

---

Ultimately, I am concerned that there may be other issues that my teachers and peers have been unaware of. I am currently looking at expanding into a much larger project, and it would be much easier to curve my behavior now, than correct it later.

What concerns do I face, if I provide excessive alternative constructors or methods for my classes?

• I am not as concerned about aesthetic and standards issues, though a good answer might mention them. I do try to follow C# standards, but not always.
• I do have concerns about the potential resource requirement this might pose, so a good answer might acknowledge any issues this may have, there.
• As I had mentioned, I am writing for Unity. I am aware that while most C# conventions are standard, there are a few variations, in context of running in Unity. Bonus points for addressing this, specifically, but a good answer will address using the language, in general.

Answer 1

The problem with your approach is that it is a violation of the Don't Repeat Yourself principle (also known as "DRY"). Adding "convenience constructors" that pass parameters along to dependencies increase code coupling between the two modules (specifically, control coupling), which is, generally, a practice that should be avoided.

However, there is one situation when you should prefer convenience constructors: it happens when GridCoordinates and TitleCode are considered implementation details of Title, and therefore should not be exposed. When this is the case, you should expose only the last constructor, and remove all constructors that rely on GridCoordinates and TitleCode from the public interface of your class.