Header Ads Widget

Ticker

6/recent/ticker-posts

La diferencia entre un acoplamiento apretado y un acoplamiento flojo

Muchas tendencias de programación modernas, como microservicios, contenedores y API, tienen un fuerte sentido de acoplamiento flexible. En otras palabras, los servicios ahora están diseñados para ser reutilizables e intercambiables, sin romper las interconexiones existentes. Desde hace algunos años, la industria del software se ha alejado de las integraciones personalizadas que implican Tight Coupling. Pero, ¿qué significan exactamente estos términos? Hoy, vamos a definir qué acoplamiento suelto y acoplamiento apretado desde un ángulo general de programación de computadoras, y exploraremos lo que estos paradigmas significan para el diseño y la implementación de API web.

¿Qué es el acoplamiento?

Los componentes estrechamente acoplados están construidos para adaptarse a un propósito singular, dependen unos de otros y no son fácilmente reutilizables.
Los servicios de software conectados están, en términos generales, más estrechamente acoplados o menos acoplados. Tight Coupling es la idea de vincular recursos a funciones y propósitos específicos. Los componentes estrechamente acoplados pueden vincular cada recurso a un caso de uso particular, una interfaz específica o una interfaz específica.
En esencia, un sistema estrechamente acoplado está diseñado específicamente y cada desviación personalizada del estándar viene con sus propios recursos e integraciones. Esta es una forma simple de construir relaciones de datos y es beneficiosa en términos de comprensión, confianza e interacción con dicha información. Sin embargo, Tight Coupling trae pérdidas claras en la extensibilidad y escalabilidad del software.
El acoplamiento suelto , sin embargo, es el paradigma opuesto. En un sistema débilmente acoplado, los componentes están separados entre sí. Cada recurso puede tener múltiples interfaces o aplicaciones. Lo contrario también es cierto para cada uno de esos elementos. Todos los sistemas pueden funcionar de forma independiente, como parte de un grupo más grande de sistemas, o en estrecha colaboración con múltiples grupos de sistemas segmentados. En última instancia, nada se ve obligado a relacionarse con cualquier otra cosa, lo que ofrece beneficios obvios en cuanto a extensibilidad y escalabilidad. La salvedad es a menudo una mayor complejidad general.
Para un ejemplo de acoplamiento suelto, tome un CMS sin cabeza . Headless CMS separa el backend del front-end, lo que significa que los desarrolladores pueden reutilizar e interactuar con el mismo backend habilitado para API desde cualquier navegador, plataforma o dispositivo cliente.

Acoplamiento flojo como mejor práctica

Los componentes desacoplados o débilmente acoplados son más independientes y reutilizables, lo que mejora la extensibilidad general.
El acoplamiento flojo y apretado son conceptos bastante generales. Entonces, ¿qué casos de uso pueden beneficiarse de cada enfoque en la práctica?
Antes de hablar sobre Tight Coupling, debe tenerse en cuenta que Loose Coupling es, con mucho, el paradigma más deseado para el desarrollo de API RESTful. Las API RESTful deberían poder transformar, mezclar, escalar, extender y transformar de un caso de uso a otro en varios recursos. En esencia, una implementación REST adecuada debe ser tanto en capas como sin estado: debe existir en gran medida independientemente de un caso de uso único y debe responder con toda la información necesaria para interactuar con todas las solicitudes.
Incluso fuera de los requisitos para un diseño RESTful auténtico, Loose Coupling es una implementación excelente para la mayoría de los casos de uso modernos. Cualquier tipo de API debería requerir un mínimo de trabajo nuevo para aprovechar, lo que permitirá a los desarrolladores utilizar su conocimiento en múltiples implementaciones e interfaces. Menos implementaciones personalizadas significan un mayor esfuerzo en la construcción de la función principal, en lugar de crear aplicaciones e interfaces individuales para cada nuevo recurso.
Además, algunas ganancias de seguridad significativas vienen con un acoplamiento flexible. Dado que no hay un millón de versiones diferentes de un millón de interfaces diferentes para cada recurso, la cantidad de datos que deben protegerse y actualizarse podría reducirse drásticamente. El acoplamiento suelto, en efecto, conduce a un ecosistema mucho más seguro.
Finalmente, los componentes inteligentes y tontos están en gran parte aislados entre sí, lo que reduce la sobrecarga. En otras palabras, los componentes inteligentes que requieren más conocimiento o datos para funcionar pueden hacerlo hablando con una API centralizada. Los componentes tontos que no necesitan saber mucho pueden operar de forma independiente sin competir con recursos o requisitos únicos y acoplados.
En última instancia, el acoplamiento flojo conduce a una menor interdependencia entre los componentes y reduce el riesgo de cambios rotos.

Acoplamiento estrecho como alternativa

Si el acoplamiento suelto tiene tantos beneficios, ¿por qué considerar el acoplamiento apretado? Si bien es cierto que el acoplamiento estrecho no es óptimo para la mayoría de microservicios y diseños RESTful, tiene un lugar en aplicaciones específicas.
El beneficio principal de Loose Coupling es que los recursos se desacoplan de la interfaz para permitir una mayor cantidad de API y esquemas de recursos interoperables y extensibles. Sin embargo, no todos los servicios requieren esto. Hay algunos casos en los que se tiene un solo recurso y una sola interfaz de un solo tipo. En tal caso, las API de propósito único a menudo están vinculadas a casos de uso único y flujos de trabajo únicos.
El acoplamiento suelto también introduce una mayor complejidad en un sistema. Algunos flujos de trabajo solo utilizan un dispositivo, una interfaz y una API. Si solo se planea una implementación, Tight Coupling podría hacer un esfuerzo de desarrollo mucho más simple. A menos que exista una gran posibilidad de que la aplicación se mueva a algo más general, se prefiere la simplicidad.

Acoplamiento no permanente

Si bien los acoplamientos apretados y sueltos son ciertamente los estilos más evidentes, existe otro tipo de acoplamiento. El acoplamiento no permanente es técnicamente un tipo de acoplamiento híbrido que no encaja en ninguna categoría. El acoplamiento no permanente podría utilizar factores basados ​​en el tiempo o la ubicación para acoplar o desacoplar componentes. En la práctica, a menudo todavía cae bajo el paraguas de un acoplamiento flojo o estrecho, pero el comportamiento es lo suficientemente único como para definirse aquí por separado.
El acoplamiento temporal es la idea de que los recursos solo pueden ser utilizados por un recurso cuando otro recurso ha respondido a la solicitud inicial. El recurso y la interfaz están completamente desacoplados hasta que se crea una pareja por tiempo limitado. Si bien esto debe evitarse la mayor parte del tiempo, hay algunos ejemplos en los que esto podría ser válido. Una aplicación de seguridad que gestiona el acceso remoto a un espacio de trabajo, por ejemplo, podría utilizar el acoplamiento de tiempo para restringir el acceso a la API de conexión de ascensor hasta que el servicio de credenciales autorice al usuario solicitante.
Relacionado con esto está el acoplamiento de ubicación , un paradigma en el que el recurso se acopla a una interfaz que depende de la proximidad de los dos. Por ejemplo, una API de servicios locales podría estar estrechamente relacionada con estar muy cerca del recurso, como requerir que alguien esté en la oficina y acceder a través de una máquina conocida y confiable para acceder a los recursos. En este caso, la pareja solo se crea cuando el usuario está cerca del recurso en un área delimitada geográficamente.

Implementaciones de acoplamiento flojo y apretado

Para ver un ejemplo de cómo funcionan estos dos paradigmas en la práctica, hay un ejemplo de código excelente que se puede encontrar en C # Corner . Lo replicamos a continuación para fines de comentario.
Let’s start with a simple Tight Coupling situation. Imagine we are coding a remote control application in C#. The following code represents this scenario:
namespace
TightCoupling
{
    public class Remote
 {
       private  Television Tv  { get; set;}
       protected Remote()
    {
        Tv = new Television();
    }
       static Remote()
    {
        _remoteController = new Remote();
    }
       static Remote _remoteController;
       public static Remote Control
    {
           get
        {
               return _remoteController;
        }
    }
         public void RunTv()
      {
          Tv.Start();
      }
 }
}
El beneficio obvio de este tipo de enfoque es la simplicidad: en un puñado de líneas de código, tenemos un esqueleto de control remoto muy simple. Dicho esto, existen grandes problemas con este enfoque. Al acoplar estrechamente la interfaz (el control remoto) y el recurso (TV), se crea una relación en la que ninguno de esos elementos puede funcionar sin el otro. El televisor no se puede cambiar sin el control remoto, el control remoto no puede controlar nada más que el televisor y los cambios afectan directamente al otro. Esto podría ser aceptable si el televisor y el control remoto son los únicos dispositivos en este ecosistema. Sin embargo, si el fabricante quisiera una mayor extensibilidad para controlar otros dispositivos, esto no sería posible con el enfoque actual.
Para resolver esto, consideremos un enfoque más débilmente acoplado. El siguiente código es tanto la clase remota como la clase de gestión para la instancia remota:
public interface IRemote
 {
        void Run();
 }
public class Television : IRemote
 {
        protected Television()
     {
     }
        static Television()
     {
         _television = new Television();
     }
        private static Television _television;
        public static Television Instance
     {
            get
         {
                return _television;
         }
     }
        public void Run()
     {
            Console.WriteLine("Television is started!");
     }
 }
public class Remote
    {
         IRemote _remote;
        public Remote(IRemote remote)
        {
            _remote = remote;
        }

        public void Run()
        {
            _remote.Run();
        }
    }
Este enfoque requiere un fragmento de código para su uso real, que se muestra a continuación:
class Program
{
        static void Main(string[] args)
        {
            Remote remote = new Remote(Television.Instance);
            remote.Run();
            Console.Read();
        }
    }
El principal inconveniente aquí es evidente a primera vista: el código es bastante más complejo que el enfoque de acoplamiento estrecho más sencillo. Dicho esto, obtiene algunos beneficios importantes.
En primer lugar, amplía la usabilidad y la extensibilidad a un nivel mucho más alto. Con el control remoto y el televisor separados uno del otro, se pueden agregar, expandir y desarrollar nuevas funcionalidades sin prácticamente ningún impacto entre el recurso y la interfaz. Esto esencialmente modulariza la totalidad de la interfaz y el flujo de datos, lo que permite que el desarrollo ocurra en muchos niveles diferentes.
Otra ventaja importante es que cada componente se puede probar y trabajar de forma aislada. En nuestro paradigma original estrechamente acoplado, estábamos limitados en nuestro enfoque de prueba, ya que solo podíamos verificar la totalidad del flujo de datos. Con todo modularizado, podemos probar cada componente individual.
Quizás el mejor beneficio aquí es que podemos combinar y ampliar cada clase. Por ejemplo, supongamos que nuestro control remoto no es solo para televisores; es posible que queramos controlar el aire acondicionado, un altavoz inteligente o un refrigerador. Si usáramos un módulo IR o BlueTooth, es posible que deseemos que todos los comandos se alimenten en una única función de emisor. Si bien el comando específico obviamente sería diferente, la función subyacente seguiría siendo la misma. Con un sistema débilmente acoplado, estas funciones podrían combinarse en una interfaz singular, pero cada una podría ser parte de un conjunto de códigos diferente con diferentes funciones extensibles.
En un paradigma estrechamente acoplado, cada una de estas funciones individuales debería desarrollarse explícitamente para el caso de uso específico, lo que sería casi más complicado que simplemente trabajar en un paradigma flexible.

La elección óptima

Normalmente, nuestra sugerencia es algo así como "depende ... observe su caso de uso y luego decida si cada opción es apropiada". Sin embargo, este es uno de los pocos casos en los que seremos más directos: el acoplamiento estrecho casi siempre es inapropiado para el diseño de API RESTful . El desacoplamiento de componentes generalmente brinda una mejor extensibilidad y ayuda a preparar un sistema para el futuro. El acoplamiento apretado se recomienda solo en circunstancias muy raras (generalmente no REPOSO). En tal caso, no tenga miedo de usar un acoplamiento estrecho, pero considere si sus suposiciones iniciales son correctas.
¿Qué opinas del acoplamiento? ¿Es esta una evaluación justa de los beneficios y los inconvenientes de cada paradigma? Háganos saber en los comentarios a continuación.

Publicar un comentario

0 Comentarios