¿Qué es el desacoplamiento y a qué áreas de desarrollo se puede aplicar? [cerrado]

21

Recientemente noté el desacoplamiento como tema en una pregunta, y quiero saber qué es y dónde se puede aplicar.

Por "dónde se puede aplicar", quiero decir:

¿Solo es relevante cuando están involucrados lenguajes compilados como C y Java?

¿Debo saber / estudiarlo como desarrollador web?


fuente
Sería útil si investigara un poco y hiciera una pregunta basada en partes poco claras de la definición.
JeffO
2
@JeffO - Creo que el mundo se beneficia tanto de las preguntas de concepto completo como de las preguntas específicas de matices. "¿Porque el cielo es azul?" permite que las respuestas cubran el concepto en sí sin entrar en detalles extremos sobre los detalles. Es por eso que seguí adelante y formulé mi pregunta sin investigar.
¿Cuál es el problema específico que tienes? Tal como está ahora, su pregunta es mucho demasiado amplia. En esta forma actual, la respuesta es esencialmente el texto completo de Diseño estructurado: fundamentos de una disciplina de diseño de sistemas y programas de computadora por Edward Yourdon y Larry Constantine .
Jörg W Mittag
Creo que las respuestas aquí hacen un trabajo perfecto al describir el concepto. Es como preguntar "¿Cuál es la definición de esta palabra en relación con la programación"? ¿Cómo, entonces, es demasiado amplia? @ GlenH7
1
@ jt0dd, tendría que estar de acuerdo. El hecho de que pueda explicar algo con un libro no significa que no haya valor en una respuesta más sucinta. Con la literatura de programación, las personas a menudo lo inundan de detalles antes de brindar una descripción general de nivel superior decente. "¿Qué es OOP?" Sería demasiado amplio. Pero este es un tema razonablemente específico de la OMI.
Erik Reppen

Respuestas:

57

'Acoplamiento' es un término que describe la relación entre dos entidades en un sistema de software (generalmente clases).

Cuando una clase usa otra clase, o se comunica con ella, se dice que 'depende' de esa otra clase, por lo que estas clases están 'acopladas'. Al menos uno de ellos 'sabe' sobre el otro.

La idea es que deberíamos tratar de mantener el acoplamiento entre clases en nuestros sistemas lo más 'flojo' posible: por lo tanto, 'acoplamiento flojo' o, a veces, 'desacoplamiento' (aunque en inglés 'desacoplamiento' significaría 'ningún acoplamiento en absoluto', la gente a menudo lo usa para implicar 'acoplamiento flojo' entre entidades)

Entonces: ¿qué es el acoplamiento flojo versus el acoplamiento fuerte en la práctica, y por qué deberíamos hacer que las entidades se acoplen libremente?


El acoplamiento describe el grado de dependencia entre una entidad y otra entidad. A menudo clases u objetos.

Cuando la Clase A depende en gran medida de la Clase B, las posibilidades de que se vea afectada cuando se cambia la Clase B son altas. Este es un fuerte acoplamiento.

Sin embargo, si la Clase A depende ligeramente de la Clase B, entonces las posibilidades de que la Clase A se vea afectada de alguna manera por un cambio en el código de la Clase B son bajas. Esto es acoplamiento flojo, o una relación 'desacoplada'.

El acoplamiento flojo es bueno porque no queremos que los componentes de nuestro sistema dependan mucho entre sí. Queremos mantener nuestro sistema modular, donde podamos cambiar de manera segura una parte sin afectar la otra.

Cuando dos partes se acoplan libremente, son más independientes entre sí y es menos probable que se rompan cuando la otra cambia.

Por ejemplo, al construir un automóvil, no querrá que un cambio interno en el motor rompa algo en el volante.

Si bien esto nunca sucedería por accidente al construir un automóvil, a los programadores les ocurren cosas similares todo el tiempo. El acoplamiento flojo está destinado a reducir el riesgo de que tales cosas sucedan.

El acoplamiento fuerte generalmente ocurre cuando la entidad A sabe demasiado sobre la entidad B. Si la entidad A hace demasiadas suposiciones sobre cómo opera la entidad B o cómo se construye, entonces existe un alto riesgo de que un cambio en la entidad B afecte a la entidad A. Esto es porque uno de sus supuestos sobre la entidad B ahora es incorrecto.

Por ejemplo, imagine que, como conductor, haría ciertas suposiciones sobre cómo funciona el motor de su automóvil.

El día que compre un automóvil nuevo con un motor que funcione de manera diferente (o por alguna razón se reemplazó su motor), sus suposiciones anteriores serían incorrectas. Si fuera código en una computadora, ahora sería un código incorrecto que no funciona correctamente.

Sin embargo, si todas las suposiciones que hizo como conductor acerca de los automóviles es que: A- tienen volantes y B- tienen pedales de freno y de gas, entonces los cambios en el automóvil no lo afectarán, siempre que sus pocas suposiciones mantente correcto Esto es acoplamiento flojo.


Una técnica importante para lograr un acoplamiento flojo es la encapsulación. La idea es que una clase oculta sus detalles internos de otras clases y ofrece una interfaz estrictamente definida para que otras clases se comuniquen con ella.

Así, por ejemplo, si se está definiendo un coche de clase, su interfaz (métodos públicos) sería probablemente drive(), stop(), steerLeft(), steerRight(), getSpeed(). Estos son los métodos que otros objetos pueden invocar en los objetos Car.

Todos los demás detalles de la clase Car: cómo funciona el motor, el tipo de combustible que usa, etc., están ocultos de otras clases, para evitar que sepan demasiado sobre Car.

En el momento en que la clase A sabe demasiado sobre la clase B: tenemos una relación fuertemente acoplada, donde la clase A es demasiado dependiente de la clase B y es probable que un cambio en la clase B afecte a la clase A. Haciendo que el sistema sea difícil de expandir y mantener.

Una relación entre dos entidades, donde se conocen poco entre sí (solo lo que es necesario), es una relación débilmente acoplada o desacoplada.

Aviv Cohn
fuente
3

El desacoplamiento generalmente se trata de ver si dos cosas deben trabajar juntas de manera estrecha o si pueden hacerse independientes. La independencia es excelente porque hace que esas cosas sean fáciles de cambiar o usar en otro lugar. El desacoplamiento se puede aplicar en muchas áreas, no solo en el desarrollo, y esto es especialmente cierto para el desacoplamiento temporal, que incluso se puede aplicar en su vida diaria (hasta cierto punto). También observando que hay muchos tipos de acoplamiento en el desarrollo de software a considerar, y no todos serán cubiertos en la respuesta. Tendrás que hacer tu investigación.

Dos cosas, A y B , se acoplan si hay una dependencia entre ellas. Si A depende de B, puede usar B sin tener en cuenta A. Si desea usar A, también tendrá que cargar B, ya que A depende de ello.

En el desarrollo de software, por lo general, no puede eliminar el acoplamiento entre componentes por completo. Desacoplar en ese contexto normalmente significa aflojar el acoplamiento existente. Es decir, asegurarse de que cada componente sepa lo menos posible sobre los otros componentes que lo rodean.

Este es probablemente el tipo de acoplamiento más común que se encuentra en la naturaleza:

//Inside a class meant to display info for a particular Facebook user.
void DisplayFriends(FacebookUser user, FacebookClient client)
{
     Friend[] = (Friend[])client.GetConnection().ExecuteCommandForResult("getFriends:" + user.Name);
     ...
}

Aquí DisplayFriends opera innecesariamente manualmente con la conexión detrás del cliente de Facebook para obtener lo que necesita. DisplayFriendsLa clase de está unida a ambos FacebookClienty Connection. Si FacebookClient cambia repentinamente el tipo de conexión que usa, la aplicación ya no podrá obtener amigos de Facebook. Podemos eliminar el acoplamiento entre la clase de DisplayFriends y Connection pidiéndole a FacebookClient que proporcione lo que necesitamos para nosotros.

//Inside a class meant to display info for a particular Facebook user.
void DisplayFriends(FacebookUser user, FacebookClient client)
{
     Friend[] = client.GetFriends(user);
     ...
}

Ahora realmente no nos importa cómo FacebookClient consigue a nuestros amigos. Todo lo que realmente nos importa es el hecho de que los atrapa. Cualquier cambio en su comportamiento interno no dañará nuestra propia clase.

Este tipo de desacoplamiento se puede lograr fácilmente siguiendo la Ley de Demeter para funciones, que dice (citando Wikipedia):

La Ley de Demeter para funciones requiere que un método m de un objeto O solo invoque los métodos de los siguientes tipos de objetos:

  • O mismo
  • parámetros de m
  • Cualquier objeto creado / instanciado dentro de m
  • Objetos componentes directos de O
  • Una variable global, accesible por O, en el alcance de m

Como mencioné sobre el acoplamiento temporal al comienzo de la respuesta, lo describiré en breve.

El acoplamiento temporal normalmente se considera al diseñar aplicaciones que ejecutan algoritmos en paralelo. Considere dos unidades ejecutables (ya sean instrucciones reales, métodos o lo que desee que considere una unidad), A y B. Decimos que A está temporalmente acoplado a B si B debe ejecutarse antes de ejecutar A. Si A no está acoplado temporalmente a B, A y B pueden ejecutarse al mismo tiempo. Cree su propio ejemplo para este: piense en las cosas habituales que hace en su vida diaria. ¿Hay dos cosas que haces una tras otra, pero que podrías hacer al mismo tiempo?

Finalmente, para responder tu último bit:

¿Debo saber / estudiarlo como desarrollador web?

Si. Por ejemplo, uno de los patrones de diseño más populares para el desarrollo web (MVC) tiene que ver con el desacoplamiento.


fuente
1

Las otras respuestas hacen un buen trabajo al describir qué es el desacoplamiento. Quería discutir tu pregunta final.

¿Debo saber / estudiarlo como desarrollador web?

La respuesta es un rotundo si. No importa qué tipo de desarrollador seas. Podría ser un desarrollador web o un desarrollador de sistemas integrados.

Supongamos que tiene una clase que genera URL personalizadas que se colocan en su página web. Puede sentirse tentado de que la clase escriba las URL directamente en la página, colocándolas en el href de una etiqueta. Esto puede parecer más simple al principio. Pero, ¿qué sucede cuando necesita hacer un cambio para poner los enlaces en un correo electrónico y enviarlos a un usuario? Su código actual no funcionaría porque su generador de URL está estrechamente acoplado al marco web que está utilizando.

La mejor opción sería tener una clase de generador de URL que devuelva la URL como una cadena. Esto podría ser utilizado por su código web y también podría ser utilizado por su código de correo electrónico. Puede parecer más trabajo por adelantado tener un código desacoplado, pero el esfuerzo se amortiza con el tiempo.

Tener un código que esté modularizado y desacoplado hará que su código sea más comprensible, más comprobable y más fácil de mantener, sin importar en qué dominio de programación esté trabajando.

epotter
fuente
Después de esta y las otras dos respuestas, realmente entiendo esto y veo cómo puedo usarlo.