Desacoplamiento vs YAGNI

Question

¿Se contradicen?

El desacoplamiento es algo grande y bastante difícil de lograr. Sin embargo, en la mayoría de las aplicaciones realmente no lo necesitamos, así que puedo diseñar aplicaciones altamente acopladas y casi no cambiará nada más que los efectos secundarios obvios, como "no se pueden separar componentes", la prueba de la unidad es un problema en el culo " etc.

¿Qué piensas? ¿Siempre tratas de desacoplar y lidiar con los gastos generales?

Answer 1

Me parece que el desacoplamiento y YAGNI son virtudes muy complementarias. (Acabo de notar la respuesta de Rob, y parece que estamos en la misma página aquí). La pregunta es cuánto desacoplamiento debe hacer, y YAGNI es un buen principio para ayudar a determinar la respuesta. (Para aquellos que hablan de pruebas de unidad: si necesita desacoplarse para hacer su prueba de unidad, entonces YAGNI obviamente no se aplica).

Sinceramente, dudo de las personas que dicen que " siempre " desacoplar Tal vez siempre lo hacen cada vez que piensan en ello. Pero nunca he visto un programa donde no se puedan agregar capas adicionales de abstracción en algún lugar, y dudo sinceramente que exista un ejemplo no trivial de tal programa. Todo el mundo dibuja una línea en algún lugar.

Desde mi experiencia, he desasociado el código y nunca he aprovechado la flexibilidad adicional con la frecuencia con la que he dejado el código acoplado y luego tuve que volver y cambiarlo más tarde. No estoy seguro de si eso significa que estoy bien equilibrado o igualmente roto en ambas direcciones.

Answer 2

YAGNI es una regla de oro (no una religión). El desacoplamiento es más o menos una técnica (tampoco una religión). Así que no están realmente relacionados, ni se contradicen entre sí.

YAGNI es sobre el pragmatismo. Supongamos que no necesita algo, hasta que lo haga.

Por lo general, suponiendo que los resultados YAGNI se desacoplan. Si no aplica ese cuchillo en absoluto, termina asumiendo que necesita tener clases que sepan todo sobre el comportamiento del otro antes de haber demostrado que eso es cierto.

" desacoplar " (o " pareja suelta ") es un verbo, por lo que requiere trabajo. YAGNI es una presunción, para la cual se ajusta cuando descubre que ya no es cierto.

Answer 3

Yo (casi) siempre me desacoplo. Cada vez que lo hacía, lo encontraba útil, y (casi) cada vez que no lo hacía, tenía que hacerlo más tarde. También he encontrado una buena forma de disminuir el número de errores.

Answer 4

Yo diría que no lo hacen. El desacoplamiento consiste en reducir las dependencias innecesarias dentro del código y en restringir los accesos a través de interfaces limpias y bien definidas. "No lo vas a necesitar" es un principio útil que generalmente desaconseja la extensión excesiva y la arquitectura demasiado amplia de una solución donde no hay un caso de uso obvio y actual.

El resultado práctico de estos es que tiene un sistema en el que es mucho más fácil refactorizar y mantener los componentes individuales sin causar inadvertidamente un efecto dominó en toda la aplicación, y donde el diseño no tiene aspectos innecesariamente complicados, es tan simple como se requiere para cumplir con los requisitos actuales.

Answer 5

El desacoplamiento por el bien del desacoplamiento puede ser malo. Sin embargo, construir componentes comprobables es muy importante.

La parte difícil de la historia es saber cuándo y cuánto desacoplamiento necesitas.

Answer 6

Si " la prueba de unidad es un dolor en el culo " entonces diría que do lo necesita. La mayoría de las veces, el desacoplamiento también se puede lograr con un costo prácticamente nulo, ¿por qué no querría hacerlo?

Además, uno de mis mayores errores cuando estoy trabajando en una nueva base de código es tener que desacoplar el código antes de que pueda comenzar a escribir pruebas unitarias cuando la introducción de una interfaz en algún lugar o el uso de la inyección de dependencia puede ahorrar mucho tiempo

Answer 7

Como dice su etiqueta, es altamente subjetivo. Depende completamente de su propia sabiduría de ingeniería para decidir lo que "no va a necesitar". Puede que necesite acoplamiento en un caso, pero no lo hará en otro. ¿Quién es para decir? Tú , por supuesto.

Para una decisión tan subjetiva, entonces, no puede haber una pauta para prescribir.

Answer 8

Bueno, YAGNI es poco más que una falsa frase simplista que la gente usa. Sin embargo, el desacoplamiento es un concepto bastante bien entendido. YAGNI parece implicar que uno es algún tipo de psíquico. Es solo programación por cliché, lo que nunca es una buena idea. Para ser honesto, se puede argumentar que YAGNI probablemente no esté relacionado con el desacoplamiento en absoluto. El acoplamiento suele ser " más rápido " y " quién sabe si usted va a necesitar una solución desacoplada; ¡De todos modos no vas a cambiar el componente X! "

Answer 9

YAGNI the mess :) ... realmente, no necesitamos mezclar todo el código para ir " más rápido " ;.

Las pruebas unitarias realmente ayudan a sentir cuando está acoplado (dado que uno entiende bien qué es una prueba unitaria frente a otros tipos de pruebas). Si en cambio lo hace con el " no puede separar los componentes " mentalidad, puedes agregar fácilmente cosas que no vas a necesitar :)

Yo diría que YAGNI aparece cuando empiezas a torcer y cambiar la lógica más allá de los escenarios de uso reales que exige la implementación actual. Digamos que tiene algún código que utiliza un par de proveedores de pago externos que trabajan con redirecciones a un sitio externo. Está bien tener un diseño que lo mantenga todo limpio, pero no creo que esté bien comenzar a pensar en proveedores que no sabemos si alguna vez recibiremos apoyo, que tienen muchas formas diferentes de manejar la integración y las aplicaciones relacionadas. flujo de trabajo.