Qual é a diferença entre uma ponte, um mediador e um invólucro?

Os slides do meu curso em arquitetura de software sugerem que esses são termos separados, mas não consigo encontrar a diferença. Todos eles não estão apenas traduzindo interfaces?

Era muito comum a pesquisa inicial de padrões colocar muita ênfase no "uso pretendido" de um padrão, além de quaisquer diferenças estruturais na implementação. Então, as pessoas que estavam naquele estágio de maturidade arquitetônica em que estavam "fazendo padrões porque padrões é o que você faz" desenvolveram explicações longas e muitas vezes elaboradas sobre por que essas supostas diferenças eram importantes.

No entanto, pesquisas mostraram que a estrutura é realmente tudo o que importa, porque as distinções semânticas:

• não têm distinções formais, mesmo no tratamento matemático da teoria dos tipos
• não são aplicáveis ​​sem diferenças sintáticas no desenvolvimento das relações de tipo (o compilador precisa de algo para impor)
• portanto, mude com a mudança de requisitos
• e não deve ser forçado a não mudar, pois a reutilização é o ponto de uma boa arquitetura

Muitas dessas grandes discussões sobre por que a estratégia é diferente do Estado resultaram bastante trabalhosas, pouco convincentes, ineficazes e levemente engraçadas com o passar dos anos.

Minha sugestão é ignorar qualquer discussão "usada para" e focar completamente nos relacionamentos de tipo. Se você fizer isso, descobrirá que (dependendo da sua definição específica desses padrões, mas bastante padrão aqui)

Mediador> Ponte> Adaptador

onde a relação deve ser lida como "é implementada usando". Adaptador é um relacionamento funcional entre três ou mais tipos em uma árvore de abstração. Bridge e Mediador são relações funcionais entre quatro ou mais tipos em torno de duas árvores de abstração, definindo uma interface entre as árvores de abstração. O mediador adiciona às relações de uso do acoplamento de tipo entre nós concretos das árvores de abstração.

Normalmente, o mediador é um padrão ruim (antipadrão) que não escala bem e faz com que um aplicativo se torne monolítico. É usado com muita frequência porque as pessoas leem o que fazem e dizem "ah, eu preciso disso" e usam um padrão porque, como acima, bem, os padrões são "o que você usa". Eles podem ser uma etapa intermediária ao desacoplar um aplicativo fortemente acoplado durante a refatoração, mas normalmente se você estiver executando essa etapa, é indicado e fácil o desacoplamento completo para o Bridge (com uma fábrica).

Geralmente, existem muitas noções de interfaces na ciência da computação. Você provavelmente deveria dizer que está falando sobre padrões de design. No artigo correspondente da Wikipedia , há uma classificação de diferentes padrões que esclarece as coisas:

• O padrão do mediador é comportamental (sobre a comunicação entre interfaces) e unifica várias interfaces, principalmente a maneira de se comunicar de maneira semelhante a um mediador real.

• Os outros dois são estruturais (na verdade, comparando interfaces):

  • o padrão wrapper / adaptador está focado em tornar uma interface compatível, por exemplo, se um cliente usar convenções diferentes;

  • o padrão da ponte consiste em separar o que a classe deve fazer (abstração) da maneira como ela realmente faz (implementação). Dessa forma, você pode usar a abstração sem saber como ela é implementada, o que é útil quando o código é alterado (para os dois lados).

Existem diferenças. A maioria deles é sutil o suficiente para você não se importar, mas geralmente diferem na intenção ou na implementação. A idéia geral é fornecer à classe A acesso à funcionalidade da classe B, sem que A se preocupe com o fato de B estar fazendo o trabalho (para que uma classe C possa ser substituída sem que nenhum desses objetos precise ser alterado). Essa idéia geralmente é chamada de "acoplamento flexível" e geralmente deve ser incentivada.

• Uma ponte é a definição mais básica da intenção de desacoplar A e B; esse, por si só, é o propósito. A conhece uma interface I, que B implementa. Uma classe C também pode implementar I e pode ser substituída livremente.

• Um "invólucro" ou adaptador geralmente é escrito com a intenção de alterar a interface de B para corresponder ao conjunto de funcionalidades que A espera de sua dependência I. Se A espera que eu tenha um método "DoThis ()" com três parâmetros, mas o método com a funcionalidade que A precisa em B é realmente chamado "DoThat ()" e aceita um parâmetro, um adaptador W pode ser gravado dependente de B (ou a interface IB de B), implementa I e chama B.DoThat () do próprio método DoThis () (passando o parâmetro, que pode ser obtido sem o conhecimento de A). Se C for necessário e diferir de B, um adaptador W2 diferente pode ser gravado, que pega um C e também implementa I; portanto, A, W, I, B e C não precisam ser alterados.

• Os padrões do mediador são basicamente um adaptador usado como uma ponte. Um mediador é seu próprio objeto M, que conhece B e é dado a A. Quando A chama métodos em M, essas chamadas são passadas para B. M pode fazer coisas adicionais, como fornecer comunicação bidirecional entre A e B B pode ser obrigado a alterar os dados de A ou ligar para seus membros, mas não pode saber sobre A em si. M pode resolver essa estrutura de dependência "circular" ou "muitos para muitos", permitindo que A e B dependam de M.