gotchaMinor
What's the difference between a bridge, a mediator and a wrapper?
Viewed 0 times
thewhatbridgedifferencewrapperbetweenmediatorand
Problem
The slides from my course in software architecture hints that these are seperate terms, but I can't seem to find the difference. Aren't all of them just translating interfaces?
Solution
It was very common for early patterns research to put a lot of emphasis on the "intended use" of a pattern, over and above any structural differences in the implementation. Then, people who were at that stage of architectural maturity where they were "doing patterns because patterns is what you do" developed long, often elaborate explanations on why these alleged differences were important.
However, research has shown that the structure is really all that matters, because the semantic distinctions:
So much of those large discussions on why strategy is different than state have turned out quite labored, unconvincing, ineffectual, and slightly humorous as the years have moved on.
My suggestion is to ignore any "is used for" discussion at all and completely focus on the type relationships. If you do that, then you will find that (depending on your particular definition of these patterns, but fairly standard here)
Mediator > Bridge > Adapter
where the > relation should be read as "is implemented using". Adapter is a functional relationship between three or more types around on one abstraction tree. Bridge and Mediator are functional relationship between four or more types around two abstraction trees, defining an interface between the abstraction trees. Mediator adds to the type coupling usage relationships between concrete nodes of the abstraction trees.
Typically, Mediator is a bad pattern (antipattern) that doesn't scale well and causes an application to become monolithic. It is used very frequently because people read what it does and go "oh, I need that" and use a pattern becasue, as above, well, patterns are "what you use". They may be an intermediate step while decoupling a heavily coupled application during refactoring, but typically if you are making that step, full decouple to Bridge (with a factory) is indicated and just as easy.
However, research has shown that the structure is really all that matters, because the semantic distinctions:
- have no formal distinctions, even in the mathematical treatment of type theory
- are not enforceable without syntactic differences in developing the type relations (compiler needs something to enforce)
- therefore change with changing requirements
- and should not be forced not to change, as reuse is the point of good architecture
So much of those large discussions on why strategy is different than state have turned out quite labored, unconvincing, ineffectual, and slightly humorous as the years have moved on.
My suggestion is to ignore any "is used for" discussion at all and completely focus on the type relationships. If you do that, then you will find that (depending on your particular definition of these patterns, but fairly standard here)
Mediator > Bridge > Adapter
where the > relation should be read as "is implemented using". Adapter is a functional relationship between three or more types around on one abstraction tree. Bridge and Mediator are functional relationship between four or more types around two abstraction trees, defining an interface between the abstraction trees. Mediator adds to the type coupling usage relationships between concrete nodes of the abstraction trees.
Typically, Mediator is a bad pattern (antipattern) that doesn't scale well and causes an application to become monolithic. It is used very frequently because people read what it does and go "oh, I need that" and use a pattern becasue, as above, well, patterns are "what you use". They may be an intermediate step while decoupling a heavily coupled application during refactoring, but typically if you are making that step, full decouple to Bridge (with a factory) is indicated and just as easy.
Context
StackExchange Computer Science Q#2284, answer score: 8
Revisions (0)
No revisions yet.