tipos - sobreescribir constructor c#
¿Cuántas variables debe tener un constructor? (12)
Me doy cuenta de que esta es una pregunta bastante abierta y podría obtener una variedad de respuestas, pero aquí va.
Usando C # (o Java, o cualquier lenguaje OO), ¿existe una regla general que indique cuántas variables se deben pasar al constructor? El número de variables que paso al constructor de las clases extendidas parece estar fuera de control.
En un esfuerzo por encapsular los datos de una clase, declaro que los miembros son privados, los inicializo en mi constructor y uso accesos públicos.
Aquí hay un ejemplo:
public class A
{
private int var1;
private int var2;
private int var3;
//3 variables passed in
public A(int v1, int v2, int v3)
{
var1 = v1;
var2 = v2;
var3 = v3;
}
//Properties (accessors) here
}
public class B : A
{
private int var4;
private int var5;
//5 variables passed in
public B(int v1, int v2, int v3, int v4, int v5)
: base(v1,v2,v3)
{
var4 = v4;
var5 = v5;
}
//Properties (accessors) here
}
public class C : B
{
private int var6;
private int var7;
//7 variables passed in !!!
public C(int v1, int v2, int v3, int v4, int v5, int v6, int v7)
: base(v1,v2,v3,v4,v5)
{
var6 = v6;
var7 = v7;
}
//Properties (accessors) here
}
Mis constructores generalmente pasan diferentes objetos, no solo ints. Empecé a cuestionar mi diseño cuando comencé a pasar 7 variables al constructor de la clase infantil, pero también tuve problemas para encontrar una forma diferente de hacerlo.
¿Esto se considera una mala práctica de programación? ¿Existe un límite general para la cantidad de variables que debe pasar a un constructor?
Además, puede poner un constructor privado sin parámetros, si cree que su clase solo debe establecer sus valores de propiedades a través del constructor.
Como han dicho otros, no existe una regla rígida sobre esto, realmente depende. Sin embargo, hay pruebas concretas de cuántas cosas puede captar el cerebro de una persona a la vez: esa es la regla 7 + o - 2.
Este tipo de pregunta está muy bien respondida en Code Complete por Steve McConnell. Te recomiendo que leas este libro si aún no lo has hecho.
Debes pasar todo lo necesario para construir la clase. Lo que hago a menudo cuando me encuentro transfiriendo muchas variables es crear una clase de "Configuración" para el objeto que contiene la información necesaria para construirla, pasando eso al constructor. Simplifica enormemente la creación de instancias de objetos y permite un diseño más limpio.
En general, he encontrado que si hay más de 3, eso es un signo para hacer una revisión rápida de la cordura en el diseño. Si hay más de 5, esa es una gran advertencia de que probablemente haya algo de malo en el diseño.
Sin embargo, tenga en cuenta la palabra "probablemente": al final, la única regla real es usar tantas como sea necesario para funcionar, ni más ni menos . Siempre hay excepciones y casos en los que más parámetros tienen más sentido.
Si los parámetros están relacionados de alguna manera, debe encapsularlos en una clase contenedora.
Si los parámetros no están relacionados, por ejemplo, no tiene sentido agruparlos en una clase de contenedor, es probable que su clase esté haciendo demasiadas cosas. En general, no hay ninguna razón para que una sola clase conozca 7 datos totalmente dispares. Divide tu clase en clases separadas. Puede tener sentido delegar los parámetros 3 y 4 en una subclase y 5, 6 y 7 en otra clase, por ejemplo, y tu clase principal simplemente coordina las operaciones entre ellos.
En mi humilde opinión, el uso de TDD es una perspectiva útil para evaluar este problema. Una vez que su ctor es difícil de aplicar a la unidad de prueba de la unidad o SetUp (), los argumentos de inicialización / fábrica son demasiados y relativamente demasiado estrechamente acoplados.
Es difícil poner un número difícil y rápido a lo que es "demasiado". La verdadera pregunta es esta: ¿Qué está haciendo tu clase? ¿La clase está haciendo demasiado? Si es así, es hora de dividir la clase en clases más pequeñas y concisas.
Los parámetros del constructor deben incluir tantos como sea necesario para definir las dependencias / entradas para la clase. Si la clase se reduce para tener un trabajo en la vida, entonces sus parámetros de constructor probablemente serán correctos.
Especialmente dado que las características más nuevas que le permiten establecer variables en un bloque con la creación de instancias, tiendo a usar parámetros en la creación solo para cosas que DEBEN establecerse cuando se crea la clase, en cuyo caso hago que el constructor básico sea privado o esté protegido .
Por ejemplo, si tuviera un Rectángulo de clase, podría tener sentido crear el Rectángulo constructor (doble ancho, doble altura) y hacer que el constructor Rectangle () sea privado.
Mi regla de oro personal es 5
Si necesita más, envuélvalos en una estructura u objeto.
Esto cambia cuando no tiene que inicializar el objeto. Si inicializo un objeto usando un contenedor IOC, el número de parámetros de constructure es básicamente ilimitado.
Para mí, la respuesta correcta es:
Debe ingresar tantas variables como sea necesario para configurar el objeto en un estado que no sea inválido.
Cualquier otra cosa que sea "opción", prefiero dejar como propiedades, especialmente ahora que C # proporciona los inicializadores de objetos.
Trataré de responder a esta pregunta desde una perspectiva diferente. Veo dos formas principales de usar los constructores, por lo que hay dos formas de pensar sobre cuántos parámetros son demasiados.
1) explícitamente llamados constructores
Este es el enfoque clásico en el que "nueva" sus objetos y debe especificar todos los valores de parámetros obligatorios. Esto fue completamente cubierto por otras respuestas aquí. Mi regla personal es: todos los parámetros deben caber en una línea, por lo que tendré un máximo de 3-4 parámetros.
Además, si sabes que es probable que tu clase sea capaz de manejar más casos que requieran más parámetros en el futuro, yo iría directamente con una estructura / clase. P.ej:
digamos que una clase debe manejar algunos objetos que se filtran según algunos criterios. Al principio, solo habrá 2-3 criterios. Sabiendo que es probable que tenga muchos más criterios en el futuro, enviaría directamente un objeto FilterValue desde el principio.
2) Implícitamente llamados constructores
Un caso típico es el uso de Dependency Injection . En casi todos los casos, se inyectan todos los parámetros del constructor, por lo que el objetivo del marco DI es construir los objetos por usted.
Aquí, el "sentido común" no se aplica, ya que uno puede inyectar tantos servicios como sea necesario. P.ej:
Si la persistencia de datos se realiza utilizando un patrón de unidad de trabajo que agrega cambios de cualquier cantidad de depósitos, se inyectará la unidad de clase de trabajo con todos los repositorios utilizados. Se pueden encontrar más detalles en esta respuesta de CodeReview .
Por cierto, el número teórico máximo de parámetros para un método debe ser lo suficientemente alto como para no alcanzarlo: C# y Java .
Un sistema tiene demasiados parámetros tan pronto como sea difícil recordar cómo usarlos. Si son todos enteros, 3 es demasiados. Si son tipos diferentes, puedes tener más.
Este es un olor en el libro Refactoring Martin Fowler. Esta página web contiene enlaces a refactorizaciones estándar que ayudan.
En su caso, es posible que desee considerar un objeto de generador (donde puede agregar gradualmente los parámetros y el constructor determina la clase) o un objeto de parámetro.
Una cosa que me encanta del framework 3.5 ...
new Foo {
Street = "909 Rose Ave",
City = "San Diego",
State = "CA",
FName = "Joe",
LName = "Wazowski",
ID = "987665454"
};
No se preocupe más por demasiados constructores o demasiados constructores con demasiados parámetros.