问题
0
审核中
Bridge vs Adapter
I understand that these patterns have different intentions, but still have some issues grasping them. Does bridge pattern is a subset of adapter? Because to me both of them look alike. I know that the adapter adapts one interface to another, but bridge also does the same (in example with devices and remotes we see that). Any suggestions on how should these patterns should be distinguishable?
UserEcho 的客户支持
Hi Yurii!
They look similar to you because you think of them only in terms of implementation. They both are based on the composition principle, so they do look really close if you strip all the context and rename the classes to A, B, C. In fact, if you do the same with Strategy and some others, it'll also look pretty similar.
However, this is not the right way to think of them. A pattern defines not just some piece of code, but also an underlying problem. You don't recommend using Bridge when someone struggles with converting XML to JSON. Similarly, you don't recommend using Adapter, when people are about to write an abstraction layer over operating systems. The ability to communicate a complex idea using one name is an integral part of having these patterns.
There are other aspects as well, such as potential future vectors in which the classes can evolve in different patterns. When using Adapter, you usually assume that the thing that you adapt from isn't going to change much (hell, you might not have control over that code at all). However, the abstraction part of Bridge may be very actively developed.
Hope this helps!
OK, I guess I'm understanding more of that. In the example which book provides the abstraction of remote controlling really suits well, but is it possible to think about it as a device controls are adapted to the user via remote controller? Instead of going to the device aka TV and switching it on/off we can do that via adapter aka remote control. Many thanks for your reply :)
EDITED: sometimes it's hard to get the real intention of a pattern based on the code read and no one around here that can explain these intentions (not working at the company anymore, etc)
Yurii, the patterns are certainly not part of the math domain—sadly, none of their definitions or features are set in stone, 100% provable, etc. The patterns weren't created from scratch; rather they have been discovered. The original GoF authors over the course of their careers observed 100 codebases with similar code, and they got the idea that in these 100 codebases programmers were driven by the same problem and produced more or less the same code. So, they thought maybe it would save time for any future programmer if we name such a problem and such a solution to this problem "an Adapter". In reality, of those 100 codebases, 90 may have been straightforward adapters, and the other 10 might have been something in between Adapter or Bridge. So now, you can pick and choose what pattern suits your needs, but if there's none, you can simply implement something on your own without using any pattern or create some sort of hybrid of multiple patterns and that would be totally okay. It would be just slightly harder to implement and explain to anyone else.
Ok, I see. Viewing the same problem under different angles helps to understand problem deeper. Thank you very much for your time :)