Constructor o propiedades: cuál es la mejor opción al asignar valores

Question

Cuando deberíamos usar constructor sobre propiedades o viceversa al asignar valores.

Answer 1

Un constructor es un tipo de contrato muy conveniente y potente: una forma de exigir a los consumidores que proporcionen cierta información antes de que puedan usar su objeto. Entonces, para información que es necesaria para que la instancia funcione correctamente, use parámetros de constructor. Este es el concepto subyacente de la inyección de dependencia: cualquier cosa de la que dependa para hacer su trabajo debe ser inyectada (provista) antes de comenzar.

Las propiedades pueden representar un problema interesante. En general, la experiencia me ha enseñado que siempre que sea posible, las propiedades deben ser de solo lectura y los objetos generalmente deben ser tan externamente inmutables como sea posible. Agregar un establecedor público a una propiedad es un multiplicador de complejidad para su clase. Por supuesto, siempre hay tipos de objetos, las entidades son un buen ejemplo, donde los instaladores tienen sentido. Pero para la mayoría de los objetos, el patrón de "write-to vía constructor"/"read-from via properties" para state ha reducido enormemente la complejidad y los riesgos de errores en las aplicaciones de las que he sido responsable.

Answer 2

Utiliza un constructor cuando necesita valores iniciales de cuerdo arbitrarios, y propiedades cuando desea que los valores se puedan cambiar posteriormente.

Answer 3

Use constructor si los valores de los parámetros son realmente necesarios para que se construya su objeto (sin ellos, el objeto no puede comenzar a funcionar). Utilice las propiedades para los parámetros que tienen un valor predeterminado aceptable, por lo que está bien no asignarlas en absoluto. Puede proporcionar algunos constructores adicionales que asignarán algunas propiedades como una forma abreviada, cortesía para sus usuarios.

Answer 4

Hay algunos casos en los que las propiedades mutables pueden ser preferibles:

1. Por 'puros' Los objetos de datos mutables, donde el mero establecimiento de las propiedades pueden tener efectos secundarios. Por ejemplo, puede tener un objeto que represente alguna entidad en la base de datos, pero la modificación de sus propiedades no tendrá ningún efecto hasta que realice explícitamente una operación de confirmación. El objeto es un paquete para contener datos, pero nada directamente reacciona a los cambios en los datos.

2. Si tiene una gran cantidad de estado configurable que afectará a alguna operación y muchas de las propiedades configurables tienen valores predeterminados significativos. Si estas son propiedades de la clase que realiza la operación, es típico tener alguna noción de 'congelar' el estado para que las propiedades mutables emitan excepciones mientras la operación se está ejecutando.

3. Si está desarrollando una clase que será consumida por un diseñador visual u otro sistema que dependa de la Reflexión sobre las propiedades. Por ejemplo, el sistema de enlace de datos en WPF hace un uso extenso de las propiedades mutables como una forma de comunicar las interacciones de UI. Con un diseño adecuado para gestionar estas mutaciones, puede crear algunas interfaces muy potentes y receptivas.