3 ms·

In defense of the Gang of Four's[1] intellectual lineage, AbstractAdapterFactory might sound opaque if you're not familiar with the jargon, but this one's not a

In defense of the Gang of Four's[1] intellectual lineage, AbstractAdapterFactory might sound opaque if you're not familiar with the jargon, but this one's not all that complex when you unpack it. An Adapter[2] is a fairly useful abstraction for when you've got a module that speaks one interface and you need to get it speaking the interface that's expected by some other module. It's a relatively tame kind of glue code. An Abstract Factory[3] lets you describe a way to new up instances of an abstraction. This differs from a regular factory, where you're getting instances of a concrete implementation. It's a trick that facilitates inversion of control and loose coupling. It lets you tell a module, "Here's where you get your Frobbers from" without it having to care whether the Frobbers it's going to get will be Whosit Frobers or Whatsit Frobbers or Widget Frobbers. Combined, you've got an abstraction for coupling some heterogeneous set of interfaces down to a common interface for the sake of being able to reuse devices without too much fiddling around. It's the software engineering equivalent of this page on Best Buy's website: http://www.bestbuy.com/site/travel-accessories/travel-converters-adapters/ http://www.bestbuy.com/site/travel-accessories/travel-conver... [1]: http://en.wikipedia.org/wiki/Design_Patterns http://en.wikipedia.org/wiki/Design_Patterns [2]: http://en.wikipedia.org/wiki/Adapter_pattern http://en.wikipedia.org/wiki/Adapter_pattern [3]: http://en.wikipedia.org/wiki/Abstract_factory_pattern http://en.wikipedia.org/wiki/Abstract_factory_pattern

marcosdumay 12y ago
The problem is not that the concept is too abstract. The problem is "WTF kind of problem are you solving that requires the integration of such a big number of random protocols?" About every time somebody uses something that abstract, it's not needed. It's just there because of cargo cult. That said, the very few projects that would need such thing are overepresented in a public repository, like Github, thus that small number of hits is expected.
- bunderbunder 12y ago
  In the spirit of giving other devs the benefit of the doubt, let's assume that when you just look at the presence of a particular string in a codebase that you're not familiar with, there's a good chance that you not knowing why it appears doesn't mean that there's no reason why it appears. As far as possible problems you could be working on where an AbstractAdapterFactory might be useful, a couple I can think of off the top of my head: Needing to work with a couple different but similar file formats. Needing to work with a couple different email services. Needing to support a couple different identity providers. Needing to couple new code to a legacy service in an enterprise application. In each of those cases, I'd also say the number of random protocols you might need to deal with before an AbstractAdapterFactory might become useful is 2. As soon as you've got a 2nd protocol to support, you open up the possibility that your languages type system could save you from having to bang out a lot of fiddly, brittle if-statements. And if there's any chance that you've got more than one different situation where that's useful, then it might already be worthwhile to take those different adapter factories and factor out a common, defined interface. Perhaps not because you'd ever actually use a reference that's typed to that interface, but just because it promotes standardization so you don't get a bunch of different devs dirtying up the project's code and semantic space with a bunch of different custom interpretations of the pattern.

marcosdumay 12y ago

The problem is not that the concept is too abstract. The problem is "WTF kind of problem are you solving that requires the integration of such a big number of random protocols?" About every time somebody uses something that abstract, it's not needed. It's just there because of cargo cult. That said, the very few projects that would need such thing are overepresented in a public repository, like Github, thus that small number of hits is expected.

bunderbunder 12y ago
In the spirit of giving other devs the benefit of the doubt, let's assume that when you just look at the presence of a particular string in a codebase that you're not familiar with, there's a good chance that you not knowing why it appears doesn't mean that there's no reason why it appears. As far as possible problems you could be working on where an AbstractAdapterFactory might be useful, a couple I can think of off the top of my head: Needing to work with a couple different but similar file formats. Needing to work with a couple different email services. Needing to support a couple different identity providers. Needing to couple new code to a legacy service in an enterprise application. In each of those cases, I'd also say the number of random protocols you might need to deal with before an AbstractAdapterFactory might become useful is 2. As soon as you've got a 2nd protocol to support, you open up the possibility that your languages type system could save you from having to bang out a lot of fiddly, brittle if-statements. And if there's any chance that you've got more than one different situation where that's useful, then it might already be worthwhile to take those different adapter factories and factor out a common, defined interface. Perhaps not because you'd ever actually use a reference that's typed to that interface, but just because it promotes standardization so you don't get a bunch of different devs dirtying up the project's code and semantic space with a bunch of different custom interpretations of the pattern.