Tengo una clase que para poder hacer su trabajo necesita tener 8 valores de propiedad diferentes establecidos. Quiero asegurarme de que las 8 propiedades estén establecidas antes de intentar ejecutar un método. Actualmente tengo todos los parámetros pasados y establecidos a través del constructor. ¿Hay una mejor manera de hacer esto?¿Existe alguna forma mejor de establecer muchas propiedades requeridas que enviar como parámetros en un Constructor?
Puede permitir que el objeto se cree sin especificar valores para todas las propiedades y luego el método lanzaría un InvalidOperationException si se llama antes de que el estado del objeto sea válido para la llamada a método a ejecutar, lo que en este caso significaría que 8 propiedades tendrían valores válidos.
De esta manera le da más flexibilidad al consumidor. Puede crear una nueva instancia en un momento, establecer sus propiedades en otro y solo luego llamar al método. Este es un "patrón" que se utiliza a través de la base de código .NET y al que ya se usan los desarrolladores.
Actualización:
Esto también simplifica las cosas si va a añadir otros métodos que no requieren el conjunto completo de propiedades que ser inicializado. Sí, podríamos agregar otra sobrecarga de constructor con el nuevo conjunto de propiedades, pero ¿qué sucede si tenemos 2 métodos que necesitan una propiedad del mismo tipo para inicializarse? Esto no es solucionable mediante el uso de sobrecargas de constructor.
Podría explicar por qué esto es mejor que usar el constructor y tener compilación -tiempo de seguridad? –
Una extensión de esta idea es usar contratos de código. – reinierpost
Lo uso en una circunstancia específica. Al recopilar información para una interfaz gráfica de usuario. Tengo un modelo que tiene propiedades para cada cosa que se puede establecer desde la interfaz gráfica de usuario y el objeto GUI establece esas propiedades cuando se cambia la GUI. el objeto puede verificarse para ver que todo en el formulario esté configurado correctamente. pero generalmente prefiero usar el constructor y tener seguridad de tiempo de compilación. Dicho esto, incluso el constructor no puede protegerlo de pasar nulo cuando no está permitido ... –
Si estuviera utilizando esta clase desde XAML, haría las 8 propiedades configurables individualmente y lanzaría una excepción si alguien intentara ejecutar un método sin que todas estén configuradas. También es posible que desee "congelar" el objeto una vez que se haya invocado un método y lanzar una excepción si alguien intenta establecer una propiedad en un objeto "congelado".
No voy a juzgar qué método es mejor, sin embargo.
Un constructor es la única forma de hacerlo en tiempo de compilación. La otra opción sería lanzar una excepción si no se han establecido todos los parámetros.
¿Les da los valores predeterminados? ¡Tal vez puedas darnos un poco más de contexto para que podamos ayudarte!
En mi opinión, si una clase requiere estos 8 objetos para funcionar, entonces deben pasarse al constructor y de ninguna otra manera. De todos modos, soy un gran admirador de la inyección de dependencia, pero este método también permite una mejor prueba unitaria al pasar objetos y objetos similares.
puede consolidar los parámetros en un Parameter Object y simplemente pasarlo.
Puede usar un inicializador de objetos si usa C# 3.0 en adelante. Esto es arbitrario ya sea 'mejor' o no.
se ve más bonito, parece peor para el estilo – xyz
Usar setter en las propiedades. Cuando el método utiliza la propiedad y no está establecido ya, setter lo haría por usted. Este no es el enfoque recomendado, pero podría ser necesario en algunas situaciones.
Algo similar sería trabajar
Class SomeClass
{
string name;
string Name
{
set
{
if (name == null)
name = value;
}
}
}
El constructor suena como la mejor manera de hacer esto ya que será verificada en baldosas de compilación.Por supuesto, puede tener valores predeterminados para algunas o todas las propiedades y luego para los constructores de cadena, de modo que no todas las propiedades deben establecerse en el constructor. Algo así como:
public class Person
{
public string Name { get; set; }
public double Height { get; set; }
public DateTime DoB { get; set; }
public Person(string name, double height, DateTime dob) : this(name, height)
{
this.DoB = dob;
}
public Person(string name, double height)
{
this.Name = name;
this.Height = height;
this.DoB = DateTime.Now.Date;
}
}
Esto significa que puede construir un nuevo objeto Persona que utiliza dos o tres parámetros, pero todos se establecerá (pero si utiliza dos entonces DOB obtendrá un valor predeterminado de hoy):
Person person1 = new Person("Geoff", 1.8, new DateTime(1950, 5, 12));
Person person2 = new Person("John", 1.54); // Gets default DOB
Veo bastantes API como esta - si me preguntas, necesitan ser reparadas. – reinierpost
Como regla general, tener más de tres parámetros para un método (o ctor) es confuso. –
Hay mejores respuestas en http://stackoverflow.com/questions/27064505/how-to-force-a-client-to-set-certain-properties – cja