C# clases inmutables en aplicaciones comerciales

Question

¿Por qué y cuándo necesitamos clases inmutables (es decir, Readonly) (no estoy hablando de string. ¿Estoy hablando de objetos comerciales) en las aplicaciones comerciales o de bases de datos?

¿Alguien puede darme un ejemplo de escenario en el mundo real?

Answer 1

Aunque Jon ciertamente presenta un caso convincente para los beneficios de los objetos inmutables, tomaría una táctica ligeramente diferente.

Cuando está modelando un proceso de negocio en código, obviamente lo que desea hacer es usar mecanismos en el código para representar hechos sobre el modelo. Por ejemplo, si un cliente es una especie de persona, entonces probablemente tendría una clase base de persona y una clase derivada del cliente, etc.

La inmutabilidad es solo otra de esos mecanismos. Entonces, en su proceso comercial, piense en lo que las cosas suceden una vez y luego nunca cambian, en contraste con lo que las cosas cambian con el tiempo.

Por ejemplo, considere "Cliente". Un cliente tiene un nombre. ¿El nombre de un cliente alguna vez cambia? Por supuesto. Los nombres de los clientes cambian todo el tiempo, generalmente cuando se casan. Entonces, ¿debería el cliente ser una clase inmutable? Probablemente no. Lógicamente, cuando un cliente cambia su nombre, no crea un nuevo cliente del viejo; El viejo cliente y el nuevo cliente son el mismo objeto, pero la propiedad de nombre ha cambiado.

Ahora considere "contrato". ¿Alguna vez cambia un contrato? No. Una enmienda a un contrato existente produce un contrato nuevo y diferente. Las fechas, las partes, las cláusulas, etc. en un contrato en particular se congelan en el tiempo. Un objeto de contrato podría ser inmutable.

Ahora la pregunta interesante es Qué hacer cuando un contrato menciona a un cliente y el cliente cambia su nombre. Son las interacciones entre objetos mutables e inmutables las que hacen de este un problema de diseño complicado.

Answer 2

Los tipos inmutables son más fáciles de razonar que los mutables: cuando tiene una referencia a una instancia, sabe que puede confiar en que no cambie. Puede construir un estilo funcional de trabajo, donde cualquier mutación que desee realizar se convierte en una operación que crea una nueva instancia (tal como lo hace con la cadena): esas operaciones funcionales se pueden componer de manera segura, sin preocupaciones sobre lo que sucede si una vez sucede de las operaciones cambia el objeto de una manera particular que dañaría las otras operaciones.

Una vez que haya tomado una decisión basada en el estado de un valor inmutable, sabe que la decisión seguirá siendo válida para ese valor, porque el valor en sí no podrá cambiar.

Además, la inmutabilidad es útil para el enhebrado: la inmutabilidad evita muchas de las preocupaciones sobre las carreras de datos, etc. cuando desea usar un solo objeto en múltiples hilos.

Muchos de estos beneficios pueden ser útiles para los objetos comerciales, pero debe abordar los problemas con una mentalidad diferente. En particular, si su base de datos fila no ser Inmutable (es decir, modificará filas en lugar de crear siempre nuevas "versiones" de filas), entonces debe tener en cuenta que cualquier valor dado ya no puede representar el estado de la base de datos para esa fila.

Answer 3

Una vez que haya imprimido una factura y la haya emitido al cliente, esa factura se congela en el tiempo para siempre. Cualquier ajuste debería aplicarse en una factura posterior.