Responsabilidades asociadas al seteo de un atributo

[BrianLuna]

Buenas! Planteo la siguiente duda:

Supongamos que tenemos una clase que tiene dos atributos. Uno de ellos es atributo1 y el otro atributo2 que depende del valor de atributo1.
El atributo2 es un valor calculado y supongamos que por alguna decisión válida, debe almacenarse en ese atributo aunque sea calculado.

Entonces, si en algún momento yo tuviese que actualizar atributo1, debería también llamar al método que calcula el atributo2 para que el estado del objeto sea consistente.

La duda puntual es cuál es la opción más acertada:

1. Asignar al setter de atributo1 la responsabilidad de llamar al método que calcula atributo2 disminuyendo la cohesión.
2. Que el objeto que llama al setter de atributo1 llame también al método que calcula atributo2 aumentando el acomplamiento.

Supongo que como siempre, "depende"; pero quisiera saber si hay alguna heurística en este sentido.

Muchas gracias!

[roli93]

Hola, Brian!

Si realmente es necesaria esa redundancia, probablemente la alternativa 1 sería más adecuada.

Analicemos un poco el problema de la cohesión en la Alternativa 1, recordando que las cualidades de diseño siempre son importantes en tanto terminan redundando en ventajas prácticas:

Sobre la cohesión, el problema es que un componente tenga varias responsabilidades entremezcladas. Ahora bien, cuáles son los problemas prácticos clásicamente asociados a tener varias responsabilidades en un componente (objeto/metodo/funcion/...)?

Algunos podrían ser:

a) Quieras hacer un cambio en responsabilidad A pero no en B y metas ruido.
b) Que puedan darse x separado cambios en A y B y tengas problemas de coordinación entre quienes implementan los cambios (muchas manos en el mismo código)
c) Que haya acoplamiento indeseado entre estas responsabilidades (x ej si comparten una variable local y al cambiar una, rompes la otra)
d) Que pierdas abstracción y capacidad para entender y seguir el código (si no está claro qué hace cada parte del código, es más difícil encontrar a dónde ir a corregir algo)

En este caso, si bien puede argumentarse correctamente que la Alternativa 1 es "menos cohesiva", no pierde tanto en cohesión porque, si lo pensás, atributo2 está, dada su naturaleza, íntimamente relacionado con atributo1, por ende la responsabilidad de cambiar uno es, indirectamente, la responsabilidad de cambiar al otro también. Es decir, podríamos decir que no estás teniendo un método que tiene 2 responsabilidades totalmente diferentes, sino uno que tiene una responsabilidad y una "extension circunstancial" de esa responsabilidad.

En términos prácticos, viendo los ítems de mas arriba:

a) Es poco probable que se dé xq son casi la misma responsabilidad
b) Es poco probable que si hay cambios en ambas, no sean el mismo cambio.
c) Acá el acoplamiento es inevitable y deseado (queremos que un atributo dependa del otro).
d) Acá el único problema potencial sería no delegar ese cálculo de atributo2 en otro método, pero en ambas alternativas lo incluiste.

Por otro lado, la Alternativa 2 no solo aumenta el acoplamiento, sino que encima aumenta el acoplamiento implícito (aquel que no es evidente), lo cual siempre dijimos que es peor. En este caso en particular eso se manifiesta como: Cualquier otro componente que tenga que setear atributo1 tiene que adivinar mágicamente que también tiene que llamar al otro método (o sea, al dev que lo codee le tienen que haber avisado, si no las cosas se van a romper). Ni hablar de que esta lógica se te va potencialmente a repetir en muchos lados, lo que es otra desventaja.

En definitiva, analizando con detalle, es bastante probable que la alternativa 2 te traiga más dolores de cabeza a futuro que la 1.

[BrianLuna]

Muchas gracias @roli93!

Saludos