oop - hables - Patrón visitante rompiendo la ley de Demeter?

ley de demeter poo

Question

Law of Demeter espera hacer el acoplamiento más flojo entre las clases.

Esto implica que el 90% de todos los getters / setters que exponen en clase deben ser "eliminados" y reemplazados por el método "conductual". De hecho, corresponde a la filosofía de "decir, no preguntar" porque no se espera que el cliente trate el comportamiento en sí mismo a través de la ayuda de métodos pobres getter / setter. Esto reduce el código duplicado también si la misma acción se usa en otro lugar.

Esto implica clases enormes con muchos métodos de comportamiento y el uso excesivo de la delegación si queremos respetar el principio de responsabilidad única.

Por otro lado, la definición de patrón de visitante es:

Visitor le permite definir una nueva operación sin cambiar las clases de los elementos en los que opera.

Entonces, a primera vista, parece ser lo contrario de las expectativas de la Ley de Deméter:

• Uno (visitante) implica una estructura de clase para proporcionar getter / setter para que Visitor pueda modificar los estados del objeto sin tocar la clase.

• Otro (Demeter) alienta a incluir todos los códigos de comportamiento directamente relacionados con el objeto en la misma clase.

Entonces mi pregunta es:

¿Cuándo podemos considerar que una clase está cerrada por modificación y así dejar de agregar métodos de comportamiento y así preferir agregarlos en un Visitante recién creado con el gran riesgo de que el cliente use getters / setters en lugar de métodos conductuales ya expuestos en la clase inicial? ?

Answer 1

La respuesta corta es no .

Primero, no creo que "diga, no pregunte" dice que debe eliminar todos sus getters y setters, pero que debe eliminarlos si no agregan ningún valor o exponen el estado interno. Por lo tanto, como ejemplo, los buscadores deberían intentar tanto como sea posible para devolver datos inmutables. Un ejemplo de setters es el ajuste u objetos de política , estos son objetos que no son necesarios para que una instancia funcione correctamente, pero si se proporcionan, cambian el comportamiento.

En segundo lugar, nunca he visto una descripción del patrón de visitante que implique que el objeto visitado debe tener getters y setters, para que el visitante pueda modificarlos. Como con cualquier otro objeto, la idea es usar la API pública del objeto visitado para hacer cualquier extensión . Implicando lo contrario definitivamente va en contra de la encapsulación también.

En otro tema, estoy un poco confundido acerca de su último párrafo, ya que no sé si está hablando sobre el principio de apertura / cierre, o sobre cómo construir una función utilizando el patrón de visitante.

Una nota, creo que la clave es entender que SOLID, la Ley de Demeter y todas las demás prácticas son buenas prácticas en lugar de mejores prácticas (''mejores prácticas'' es un término de marketing). Si llevas cualquiera de estas prácticas al extremo, probablemente terminen perjudicando la legibilidad o el mantenimiento del código.

(por cierto, buena pregunta: D)

El beneficio del principio de apertura / cierre se aplica principalmente al código que va a ser utilizado por otras personas en formas que no podemos anticipar (los marcos son un ejemplo de esto). Por lo tanto, si está escribiendo un marco, deberá agregar puntos de extensión y utilizar una función de idioma para evitar que la clase sea heredada (como final en Java o sellada en C #) o simplemente dejando que el desarrollador anule ciertos métodos. La idea es evitar que un usuario ingenuo sobrescriba una parte importante de un objeto y haga que el marco se rompa de forma inesperada. Algunos lenguajes / frameworks se ríen de esto (por ejemplo, Ruby / Rails) y alientan al usuario a abrir las clases para agregar o modificar características (con bastante éxito).

Si está escribiendo una aplicación (y posee el código), le sugiero que no preste demasiada atención al principio abierto / cerrado, y se concentre en aplicar la Ley de Demeter (en una medida razonable: D).