Entendendo o acoplamento solto / apertado no "mundo real"

Não direi o que é "comunidade" porque quero uma explicação não tendenciosa, mas digamos que você esteja criando um módulo reutilizável e que esse módulo exija mais de 3 módulos dependentes e a remoção de 1 deles cause um erro de quebra não apenas no seu aplicativo como um inteiro que usa este módulo, mas o próprio módulo.

Pelo que entendi (o que deve estar errado), um sistema modular fracamente acoplado não será quebrado simplesmente removendo um módulo. O aplicativo ainda deve ser executado, mas sem esse "recurso" / módulo e o próprio módulo não deve fazer com que tudo não seja executado simplesmente porque não existe um módulo dependente.

Isso está errado? Se sim, se os módulos ainda dependem de tudo o que não está funcionando, qual é a diferença entre acoplamento estanque / frouxo?

Não é bem --- remover o módulo pode muito bem danificar o sistema. A idéia por trás dos sistemas de acoplamento flexível é que a troca de um módulo completamente diferente funcionará perfeitamente desde que o novo módulo esteja em conformidade com os mesmos requisitos de interface do antigo. Se estivesse fortemente acoplado, o código ao redor faria suposições sobre os internos e começaria a falhar se um novo módulo fosse introduzido.

O acoplamento frouxo é essencialmente a dependência indireta entre os módulos de como eles podem evoluir.

Geralmente, quando existem sistemas fortemente acoplados, diferentes módulos / objetos têm comportamentos muito específicos que pressupõem esse comportamento dos objetos periféricos. Tais objetos são vinculados / acoplados a comportamentos de outros módulos e não podem ser reutilizados isoladamente ou em qualquer outro contexto.

Tais módulos, embora sejam responsáveis ​​pela funcionalidade individual, não podem evoluir independentemente ou não podem evoluir.

Um exemplo:

Digamos que você tenha 3 objetos Shape(um objeto de modelo) e Canvas(um elemento da interface do usuário). Agora

Suponha que um método shape.draw(Canvas)desenhe um objeto no plano que é fornecido pelo plano da tela.

Agora, às vezes, as janelas estão parcialmente cobertas e são redimensionadas. Nesses casos, o método acima pode fazer algo assim.

shape::draw(Canvas) {
   Rect.WindowLeft = Canvas.GetWindowRect.getLeftOffset(); 
   Rect.LeftPixel = Canvas.GetWindowRect.pixels() + Rect.WindowLeft; 
   ....  // like this get all co-ordinates. 

   draw_instance(Rect);  // This will draw the actual shape. 
}

Basicamente, aqui a função desenhar seleciona o retângulo onde as coisas precisam ser desenhadas. Isso é fácil de entender (as pessoas podem chamar isso simples ) de código. No entanto, esse é um código extremamente acoplado.

Imagine a situação:

• E se o mecanismo da tela de manter janelas não for mais um retângulo?
• e se houver compensações adicionais mantidas pelo Canvas que sejam privadas ?
• E se algum outro aplicativo desejar a mesma forma, mas não tiver mais uma janela da GUI (por exemplo, está criando imagens e salvando em arquivos).

A causa principal do problema é que objecto shape conhece e, consequentemente, firmemente acoplado com Canvas.

O que é desejável que um conjunto de pixels seja dado para moldar onde ele escreve; o shapenão deve ter (mesmo implícito) conhecimento sobre onde os pixels são realmente gravados.

Depende, mesmo do que você especificar como módulo. Algumas partes do sistema devem ser fortemente acopladas (por exemplo, suas entidades devem ser reutilizadas em todo o aplicativo), mas alguns sistemas devem estar soltos, com separações de interface ou se estamos falando em não interromper o aplicativo se você remover o módulo , esse módulo deve ser conectado de alguma forma dinamicamente, talvez por meio do contêiner de IoC ou algo assim.

Além disso, acoplamento rígido significa que alguma parte depende da implementação específica do módulo, não da definição de módulo ou algo assim.