Estoy contribuyendo esta respuesta para complementar la respuesta de Roger Alsing sobre invariantes por otras razones.
La información semántica
Roger explicó claramente que los emisores de propiedad no llevan información semántica. Permitir que un colocador de una propiedad como Post.PublishDate pueda agregar confusión, ya que no podemos estar seguros de si la publicación se ha publicado o solo si se ha establecido la fecha de publicación. No podemos estar seguros de que esto sea todo lo que se necesita para publicar un artículo. El objeto "interfaz" no muestra su "intención" claramente.
Creo, sin embargo, que las propiedades como "Habilitado" tienen suficiente semántica para "obtener" y "establecer". Es algo que debería ser efectivo de inmediato y no puedo ver la necesidad de los métodos SetActive() o Activate()/Deactivate() por la sola razón de perder semántica en el establecimiento de propiedades.
invariantes
Roger también se refirió a la posibilidad de romper invariantes a través de los emisores de propiedad. Esto es absolutamente correcto, y uno debe hacer propiedades que funcionen en tándem para proporcionar un "valor invariante combinado" (como los ángulos del triángulo para usar el ejemplo de Roger) como propiedades de solo lectura y crear un método para establecerlas todas juntas, lo que puede valide todas las combinaciones en un solo paso.
fin propiedad de inicialización/dependencias de ajuste
Esto es similar al problema con invariantes ya que causa problemas con las propiedades que deben ser validados/cambiaron juntos. Imagine el siguiente código:
public class Period
{
DateTime start;
public DateTime Start
{
get { return start; }
set
{
if (value > end && end != default(DateTime))
throw new Exception("Start can't be later than end!");
start = value;
}
}
DateTime end;
public DateTime End
{
get { return end; }
set
{
if (value < start && start != default(DateTime))
throw new Exception("End can't be earlier than start!");
end = value;
}
}
}
Este es un ejemplo ingenuo de validación "setter" que causa dependencias de orden de acceso. El código siguiente ilustra este problema:
public void CanChangeStartAndEndInAnyOrder()
{
Period period = new Period(DateTime.Now, DateTime.Now);
period.Start = DateTime.Now.AddDays(1); //--> will throw exception here
period.End = DateTime.Now.AddDays(2);
// the following may throw an exception depending on the order the C# compiler
// assigns the properties.
period = new Period()
{
Start = DateTime.Now.AddDays(1),
End = DateTime.Now.AddDays(2),
};
// The order is not guaranteed by C#, so either way may throw an exception
period = new Period()
{
End = DateTime.Now.AddDays(2),
Start = DateTime.Now.AddDays(1),
};
}
Dado que no podemos cambiar la fecha de inicio más allá de la fecha de finalización en un periodo objeto (a no ser que se trata de un período de "vacío", con las dos fechas establecidas por defecto (DateTime) - Sí, no es un gran diseño, pero entiendes lo que quiero decir ...) intentar establecer primero la fecha de lanzamiento generará una excepción.
Se pone más serio cuando usamos los inicializadores de objetos. Como C# no garantiza ninguna orden de asignación, no podemos hacer suposiciones seguras y el código puede lanzar o no una excepción dependiendo de las elecciones del compilador. ¡MALO!
Esto es en última instancia un problema con el DISEÑO de las clases. Como la propiedad no puede "saber" que está actualizando ambos valores, no puede "desactivar" la validación hasta que ambos valores realmente se cambien. Debe hacer ambas propiedades de solo lectura y proporcionar un método para establecer ambas al mismo tiempo (perder la función de los inicializadores de objetos) o eliminar el código de validación de las propiedades (quizás introduciendo otra propiedad de solo lectura como IsValid o validando siempre que sea necesario).
ORM "hidratación" *
hidratación, en una visión simplista, significa obtener los datos conservados de nuevo en objetos. Para mí, este es realmente el mayor problema al agregar lógica detrás de los establecedores de propiedades.
Muchos/la mayoría de los ORM asignan el valor persistente a una propiedad. Si tiene una lógica de validación o lógica que cambia el estado del objeto (otros miembros) dentro de los establecedores de propiedades, terminará tratando de validar contra un objeto "incompleto" (uno aún se está cargando). Esto es muy similar al problema de inicialización de objetos ya que no puede controlar el orden en que los campos están "hidratados".
La mayoría de los ORM le permiten mapear la persistencia a campos privados en lugar de propiedades, y esto permitirá que los objetos se hidraten, pero si su lógica de validación se encuentra principalmente dentro de los ajustadores de propiedades, puede tener que duplicar objeto cargado es válido o no.
Dado que muchas herramientas ORM soportan la carga diferida (un aspecto fundamental de un ORM!) A través del uso de propiedades virtuales (o métodos) el mapeo a los campos imposibilitará que el ORM cargue los objetos asignados en campos.
Conclusión
Así que, al final, para evitar la duplicación de código, permiten ORM para llevar a cabo lo mejor que pudo, impiden excepciones sorprendentes dependiendo del orden se establecen los campos, es aconsejable mover la lógica lejos de establecedores de propiedad.
Todavía estoy averiguando dónde debería estar esta lógica de 'validación'. ¿Dónde validamos los aspectos invariantes de un objeto? ¿Dónde ponemos validaciones de alto nivel? ¿Usamos ganchos en los ORM para realizar la validación (OnSave, OnDelete, ...)? Etc. Etc. Etc. Pero este no es el alcance de esta respuesta.
entonces en su ejemplo deberíamos usar una sola función como 'period.setDateBoundries (startDate, endDate)' para evitar setters? una función única que tiene un significado comercial en lugar de establecedores ficticios? – Songo
@Songo eso es lo que haría. Pero entonces uno podría quejarse para tener que pasar ambas fechas para cambiar solo una (imagínese si quisiéramos extender un período, ¡tendríamos que aprobar ambas fechas! ... pero entonces, oye, ¿por qué no creamos un método Extendido? ?) Piense de esta manera: cada vez que termina con una propiedad que depende de otra, entonces tal vez sea una buena idea introducir métodos para cambiarlos o métodos que agregarán más valor semántico (como el Período.Extender uno ...)! – Loudenvier
Estoy considerando pasar arreglos. No es genial para IDE indirecta, pero me permite pasar datos en cualquier orden. También puedo agregar u omitir datos según la circunstancia (es decir, intervalo de fecha completo o solo una fecha). La validación se realiza de todos modos, por lo que no parece mucho más una carga verificar también si se dio u omitió un parámetro. – prograhammer