为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

I see nothing wrong defining as many overloads as you see fit, as long as they are clearly documented. I'm not aware of any good practice or principle recommending to the contrary. A clear disadvantage is obviously the increases costs in code maintenance; documentation and testing whenever you need to change something.

Which brings up my major gripe with the code you've posted; what I do find worrisome in your code and I'd never write similar were it mine is so many independent implementations. If you later on decide to change the constructor logic, you'll have to change it all over the place and that will be very bug prone. I'd refactor the code to use constructor chaining and implement all construction logic in one single overload and simply chain/delegate all other constructors to that single one.

All that said, my personal opinion is that you should favor as much as possible overloads where the arguments are as "strongly typed" as possible regarding your business domain. By this I mean:

public Foo(int i, int j, int k, int n) { ... }

Is horribly error prone. A call to Foo(j, i, k, n) is perfectly valid and it can be very hard to locate in a big code base once the bug crops up, possibly well down the call stack.

However a signature of the type:

public Foo(Bar bar, Blah blah)

Is a lot safer, because the type system and the compiler can help you.

Answer 2

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.