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

7

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?

bobbaluba
fonte
3
Eu acho que você deveria oferecer um pouco mais de contexto.
Raphael
2
Publicado cruzado aproximadamente ao mesmo tempo para empilhar o estouro .
Jmad

Respostas:

8

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).

ex0du5
fonte
qual dos outros padrões "padrão" também é antipadrão, na sua opinião?
Novellizator
Eu acho que o mais comum é o Singleton. Você nunca deve forçar uma semântica em seus objetos (como apenas uma instância existente) que não é necessária para forçar (instanciar apenas uma vez se for o que você precisa). Porém, geralmente é usado para tornar o acesso "fácil" e polui o espaço global e oculta as relações de dependência.
Ex0du5
Mas o que realmente me impressiona não é visto no GoF, mas é um padrão muito comum na computação: pesquisa. A única vez em que isso é "necessário" é um hardware mal projetado. Ele nunca é necessário para o monitoramento de software, mas persiste devido a um projeto ruim de protocolo, preguiça de interface, etc. Nunca se deve gastar horários sem saber que você encontrará algo útil, e a pesquisa possui uma latência interna que raramente é útil neste formulário. A latência pode ser útil na conversão de transições, mas isso só deve ocorrer depois que uma transição for determinada. Devemos nos esforçar para sermos orientados a eventos.
Ex0du5
Realmente, porém, acho que não devemos pensar em padrões, exceto como reconhecimento. Os engenheiros devem realmente apenas projetar o que vem de sua linguagem de domínio. É daí que os tipos e suas relações vêm. Então, lembre-se da boa arquitetura - coisas como o princípio Aberto / Fechado, reutilização, contém e não herda; a herança é para bases abstratas de interfaces com poucas camadas de profundidade (de preferência apenas uma base, exceto onde as interfaces polimórficas naturalmente possuem estrutura), máquinas de estado por vida útil do estado [orientada a eventos], etc. Isso leva a escolher as relações de tipo corretas, não padrões.
Ex0du5
Você poderia apontar para a pesquisa, que "mostrou que a estrutura é realmente tudo o que importa"?
PsiX 18/07/2016
6

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).

jmad
fonte
5

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.

KeithS
fonte