sobreescritura - ¿Es mala forma proporcionar sobrecargas excesivas para un método o constructor en C#?

sobrecarga de metodos en programacion orientada a objetos

Question

Estoy escribiendo código para Unity, usando C #. En este momento, estoy tratando con algunas clases y estructuras más pequeñas, en un esfuerzo por serializar rápidamente un mapa generado aleatoriamente. Al hacerlo, trato con algunos constructores que también toman algunas de estas clases y estructuras más pequeñas, como parámetros.

En el pasado, normalmente intentaba considerar las opciones plausibles al configurar mis métodos y constructores. Si bien esta práctica ha sido cuestionada , nadie ha logrado darme ninguna razón plausible de por qué no debería hacerlo de esta manera.

Considere la siguiente clase y estructuras:

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;
}

Normalmente, cubriría todas las alternativas struct e int , al crear los constructores. Tile se vería así:

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);
}

Tiendo a hacer esto por eficiencia. Me toma una cantidad insignificante de tiempo extra escribir los constructores / métodos adicionales en conjunto con el primer constructor / método, y encuentro que esto a veces me resulta útil cuando más tarde deseo usar el constructor / método de una manera que no tenía originalmente. anticipado.

El único problema que se ha planteado anteriormente es el potencial de confusión. Siento que esto no es realmente un problema, ya que mi organización y mis comentarios distinguen claramente cada variación.

En definitiva, me preocupa que haya otros problemas que mis maestros y compañeros no hayan tenido en cuenta. Actualmente estoy buscando expandirme a un proyecto mucho más grande, y sería mucho más fácil curvar mi comportamiento ahora, que corregirlo más adelante.

¿A qué preocupaciones me enfrento si proporciono constructores o métodos alternativos excesivos para mis clases?

• No me preocupan tanto las cuestiones estéticas y de normas, aunque una buena respuesta podría mencionarlas. Intento seguir los estándares de C #, pero no siempre .
• Me preocupan los posibles requisitos de recursos que esto podría suponer, por lo que una buena respuesta podría confirmar cualquier problema que pueda tener.
• Como lo mencioné, escribo para Unity. Soy consciente de que, aunque la mayoría de las convenciones de C # son estándar, existen algunas variaciones en el contexto de la ejecución en Unity. Puntos de bonificación por abordar esto, específicamente, pero una buena respuesta abordará el uso del idioma, en general.

Answer 1

El problema con su enfoque es que es una violación del principio de "No repita usted mismo " (también conocido como "SECO"). Agregar "constructores de conveniencia" que pasan los parámetros a lo largo de las dependencias aumenta el acoplamiento de códigos entre los dos módulos (específicamente, el acoplamiento de control ), que es, en general, una práctica que debe evitarse.

Sin embargo, hay una situación en la que debería preferir los constructores de conveniencia: sucede cuando GridCoordinates y TitleCode se consideran detalles de implementación del Title y, por lo tanto, no deberían exponerse. Cuando este es el caso, debe exponer solo el último constructor y eliminar todos los constructores que dependen de GridCoordinates y TitleCode de la interfaz pública de su clase.

Answer 2

No veo nada de malo en definir tantas sobrecargas como crea conveniente, siempre y cuando estén claramente documentadas. No conozco ninguna buena práctica o principio que recomiende lo contrario. Una clara desventaja es, obviamente, los costos de aumento en el mantenimiento del código; documentación y pruebas cada vez que necesite cambiar algo.

Lo que hace que mi mayor queja con el código que ha publicado; lo que sí encuentro preocupante en su código y nunca escribiría similar si fuera una implementación independiente. Si luego decides cambiar la lógica del constructor, tendrás que cambiarla por completo y eso será muy propenso a errores. Refactorizaría el código para usar el encadenamiento de constructores e implementaría toda la lógica de construcción en una única sobrecarga y simplemente encadena / delegaría todos los demás constructores a esa sola.

Dicho todo esto, mi opinión personal es que debe favorecer la mayor cantidad posible de sobrecargas cuando los argumentos son tan "tipeados" como sea posible con respecto a su dominio comercial. Con esto quiero decir:

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

Es terriblemente propenso a errores. Una llamada a Foo(j, i, k, n) es perfectamente válida y puede ser muy difícil ubicarla en una gran base de código una vez que surge el error, posiblemente muy abajo en la pila de llamadas.

Sin embargo, una firma del tipo:

public Foo(Bar bar, Blah blah)

Es mucho más seguro, porque el sistema de tipos y el compilador pueden ayudarte.