Desacoplamiento vs YAGNI

Question

¿Se contradicen?

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

¿Qué opinas? ¿Siempre intentas desacoplar y lidiar con los gastos generales?

Answer 1

Me parece que el desacoplamiento y YAGNI son virtudes muy complementarias. (Me acabo de dar cuenta de 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 unitarias, si necesita desacoplarse para hacer su prueba unitaria, entonces YAGNI obviamente no se aplica.)

Realmente dudo mucho de las personas que dicen que "siempre" se desacoplan. Quizás siempre lo hagan cada vez que piensan en eso. Pero nunca he visto un programa donde capas adicionales de abstracción no puedan agregarse en alguna parte, y sinceramente dudo que exista un ejemplo no trivial de tal programa. Todos dibujan una línea en algún lado.

Según mi experiencia, he desacoplado el código y nunca he aprovechado la flexibilidad adicional tan a menudo como he dejado el código acoplado y luego tuve que volver atrás y cambiarlo más tarde. No estoy seguro si eso significa que estoy bien equilibrado o quebrado en ambas direcciones.

Answer 2

I (casi) siempre se desacoplan. Cada vez que hacía esto, lo encontraba útil, y (casi) cada vez que no lo hacía, tenía que hacerlo más tarde. También he descubierto que es una buena forma de disminuir el número de errores.

Answer 3

Bueno, YAGNI es poco más que una frase simplista falsa que la gente tira. Desacoplamiento, sin embargo, es un concepto bastante bien entendido. YAGNI parece implicar que uno es un tipo de vidente. Es solo programar por cliché, lo cual nunca es una buena idea. Para ser honesto, hay un caso en el que YAGNI probablemente no esté relacionado con el desacoplamiento. El acoplamiento es típicamente "más rápido" y "quién sabe si usted va a necesitar una solución desacoplada, ¡no va a cambiar el componente X de todos modos!"

Answer 4

El desacoplamiento por desacoplamiento puede ser malo. La construcción de componentes comprobables es muy importante.

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

Answer 5

Como dice su etiqueta, es muy subjetivo. Todo depende de su propia sabiduría de ingeniería para decidir lo que "no va a necesitar". Puede necesitar acoplamiento en un caso, pero no en otro. ¿Quién debe decir? Usted, por supuesto.

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

Answer 6

Yo diría que no. El desacoplamiento se trata de reducir dependencias innecesarias dentro del código y reforzar los accesos a través de interfaces limpias y bien definidas. "No lo va a necesitar" es un principio útil que generalmente desaconseja la sobreexpansibilidad y la arquitectura demasiado amplia de una solución donde no existe un caso de uso obvio y actual.

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

Answer 7

YAGNI el desastre :) ... realmente, no necesitamos tener todo el código mezclado 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 vs. otros tipos de pruebas). Si en cambio lo haces con la mentalidad de "no puedes separar componentes", puedes agregar fácilmente cosas que no vas a necesitar :)

Yo diría que YAGNI entra cuando comienzas 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 un código que usa un par de proveedores de pagos externos que funcionan 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 los proveedores que no sabemos si serán compatibles alguna vez que tengan muchas formas diferentes de manejar la integración y los aspectos relacionados. flujo de trabajo

Answer 8

Si "unidad de pruebas es un dolor en el culo", entonces yo diría que hace lo necesitan. La mayoría de las veces, el desacoplamiento se puede lograr con un costo prácticamente nulo, así que, ¿por qué no querrías hacerlo?

Por otra parte, uno de mis mayores pesadillas cuando se trabaja en un nuevo código base es tener que desacoplar el código antes de que pueda comenzar a escribir las pruebas unitarias cuando la introducción de una interfaz en algún lugar o el uso de la inyección de dependencia podrían ahorrar mucho tiempo

Answer 9

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

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

Normalmente, suponiendo que YAGNI dé como resultado el desacoplamiento. Si no aplicas ese cuchillo en absoluto, terminas asumiendo que necesitas tener clases que sepan todo sobre el comportamiento del otro antes de haber demostrado que es cierto.

"Decouple" (o "par flojo") es un verbo, por lo que requiere trabajo. YAGNI es una presunción, para la cual te ajustas cuando descubres que ya no es verdad.