Guess which language overuses AbstractAdapterFactory(github.com)
github.com
Guess which language overuses AbstractAdapterFactory
https://github.com/search?l=&q=AbstractAdapterFactory&ref=advsearch&type=Code&utf8=%E2%9C%93
23 comments
Obviously we were supposed to think that Java would be the biggest abuser of this construct. However, keep in mind that Java is severely under represented on GitHub compared to languages like PhP. Compare http://adambard.com/blog/top-github-languages-for-2013-so-fa... to http://www.tiobe.com/index.php/content/paperinfo/tpci/index.... and notice the discrepancies. In other words, sampling on GitHub is severly biased.
Look at the graph - PHP just happens to be the first result, Java still 'wins'.
There are not very many results overall though (152 total), so I'd say the real answer is none of them.
There are not very many results overall though (152 total), so I'd say the real answer is none of them.
[deleted]
I thought this was meant to be surprising, but it's Java after all.
Anyway, I'm nut sure what this is really meant to show. The only reason Java has so many references to that is because Eclipse project has an AbstractAdapterFactory, and it's a big project.
I'm sure it would be possible to doctor similar results for abstract class names for any major language by looking at large project code bases in that language.
Anyway, I'm nut sure what this is really meant to show. The only reason Java has so many references to that is because Eclipse project has an AbstractAdapterFactory, and it's a big project.
I'm sure it would be possible to doctor similar results for abstract class names for any major language by looking at large project code bases in that language.
Guess which language overuses __init__!
https://github.com/search?utf8=%E2%9C%93&q=__init__&type=Cod...
https://github.com/search?utf8=%E2%9C%93&q=__init__&type=Cod...
Guess which language overuses the number 14763! https://github.com/search?utf8=%E2%9C%93&q=14763&type=Code&r...
Python's module system is completely broken, but since it's "the best language for learning" many new programmers will never know what's wrong with it.
So, what is a better language for learning? (Genuinely curious.)
Racket. http://racket-lang.org/
[deleted]
Javascript for minimum LOC to move a ball across the screen, albeit in a constructed learning environment.
C for learning some low level concepts. probably don't get into string handling in C if you're new because it will frustrate you.
Java for implementing GUIs and forcing OO concepts
C for learning some low level concepts. probably don't get into string handling in C if you're new because it will frustrate you.
Java for implementing GUIs and forcing OO concepts
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-conver...
[1]: http://en.wikipedia.org/wiki/Design_Patterns [2]: http://en.wikipedia.org/wiki/Adapter_pattern [3]: http://en.wikipedia.org/wiki/Abstract_factory_pattern
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-conver...
[1]: http://en.wikipedia.org/wiki/Design_Patterns [2]: http://en.wikipedia.org/wiki/Adapter_pattern [3]: http://en.wikipedia.org/wiki/Abstract_factory_pattern
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.
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.
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.
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.
Reminds me of: TransactionAwarePersistenceManagerFactoryProxy
http://stackoverflow.com/questions/14636178/unsure-if-i-unde...
http://stackoverflow.com/questions/14636178/unsure-if-i-unde...
I was sure it was Java and it was it. I think, the main reason is that people who use this language adopt patterns, Domain Driven Design and other practices which lead to such abstraction mess.
Without even know what an AbstractAdapterFactory is I guessed Java. Can someone explain what it is?
This gets into deep Gang of Four / Enterprise Java architecture astronomy, but let's say you have a particular need to have objects be controllable via configuration rather than code, perhaps even being configured to use code that you did not yourself provide. This is particularly common in framework development, where you're shipping something which will be used by other developers to ship software on top of. We expect "our code" and "their code" to interact at the API level, rather than through e.g. passing JSON messages to anonymous endpoints, so we care quite a bit about having strong published APIs, little introspection into the inner workings of client classes, and forwards compatibility with use cases we may not have envisioned yet.
To accomplish some of these goals in a particular use case in a strongly typed language, you might use a weak superclass (in the instant case, Adapter [+]) in your code, and leave it to the implementing developers to select or build an Adapter appropriate for their needs. But how to delegate responsibility for actually creating those objects, after reading the configuration files or what have you? You use an intermediary class, a Factory, which takes in arguments to a predictable interface and returns objects of some subclass implementing the interface which your code expects.
But what if your Factories are also designed to be plug-and-play? For example, while the Factory concept is designed to insulate your code from the implementation of the desired class (the Adapter), maybe some adapter implementations require parameters which your Factory might not ship with knowledge of. In this case, we might make it possible to bring your own factory, complying with our published factory interface (here, an AbstractAdapterFactory -- extend it and implement the createAdapter method and boom, there you go), allowing you to use our published code.
+ What's an Adapter? Again, Gang of Four architecture astronomy, most readily explained by a common use case: it allows you to encapsulate the consequences of a verb into a noun. (Steve Yegge has an old, brilliant article on the Kingdom of Nouns that Java creates which necessitates this pattern.) For example, if you're trying to express a mouse click and its consequences in a Java UI, the control of the consequences is likely being handled by a MouseAdapter which implements some sort of onClick(MouseEvent e) method.
You can chain this sort of complexity indefinitely. For example, I think my above explanation implicates the existence of an AdapterFactoryFactory. In my late and unlamented Enterprise Java career, working in framework development, four GoF nouns in a row plus one distinguishing word wouldn't have occasioned more than a raised eyebrow.
Anyhow, turtles all the way on down. Welcome to Enterprise Java. In dynamic languages, some of this is obviated and some of it is replaced by different patterns which implement the same concerns. (An example which jumps to mind: you could have an AbstractCacheStoreFactory pretty easily in a Java web app framework. This might let you use an XML file to specify, e.g., different cache stores in production vs. development environments. In Rails, your config files are executable Ruby code and they might just directly instantiate the cache stores... or use syntactic sugar which says "I'm using one of the usual ones, so just assume you know what I mean when I say config.cache_store = :memcached.")
To accomplish some of these goals in a particular use case in a strongly typed language, you might use a weak superclass (in the instant case, Adapter [+]) in your code, and leave it to the implementing developers to select or build an Adapter appropriate for their needs. But how to delegate responsibility for actually creating those objects, after reading the configuration files or what have you? You use an intermediary class, a Factory, which takes in arguments to a predictable interface and returns objects of some subclass implementing the interface which your code expects.
But what if your Factories are also designed to be plug-and-play? For example, while the Factory concept is designed to insulate your code from the implementation of the desired class (the Adapter), maybe some adapter implementations require parameters which your Factory might not ship with knowledge of. In this case, we might make it possible to bring your own factory, complying with our published factory interface (here, an AbstractAdapterFactory -- extend it and implement the createAdapter method and boom, there you go), allowing you to use our published code.
+ What's an Adapter? Again, Gang of Four architecture astronomy, most readily explained by a common use case: it allows you to encapsulate the consequences of a verb into a noun. (Steve Yegge has an old, brilliant article on the Kingdom of Nouns that Java creates which necessitates this pattern.) For example, if you're trying to express a mouse click and its consequences in a Java UI, the control of the consequences is likely being handled by a MouseAdapter which implements some sort of onClick(MouseEvent e) method.
You can chain this sort of complexity indefinitely. For example, I think my above explanation implicates the existence of an AdapterFactoryFactory. In my late and unlamented Enterprise Java career, working in framework development, four GoF nouns in a row plus one distinguishing word wouldn't have occasioned more than a raised eyebrow.
Anyhow, turtles all the way on down. Welcome to Enterprise Java. In dynamic languages, some of this is obviated and some of it is replaced by different patterns which implement the same concerns. (An example which jumps to mind: you could have an AbstractCacheStoreFactory pretty easily in a Java web app framework. This might let you use an XML file to specify, e.g., different cache stores in production vs. development environments. In Rails, your config files are executable Ruby code and they might just directly instantiate the cache stores... or use syntactic sugar which says "I'm using one of the usual ones, so just assume you know what I mean when I say config.cache_store = :memcached.")
The Rosetta stone for this stuff for people more familiar with dynamic languages like Ruby and Python than with Java and C++:
http://norvig.com/design-patterns/
http://norvig.com/design-patterns/
People love to bash Java for AbstractAdapterFactories and the like but it really is not that bad and it has its own time and place, not that I'm particularly a fan of it.
I'm not even a Java developer but I understand it quite well.
I'll have a go at explaining it with simple ideas.
So let's break it down (from right to left):
Factory: as the name implies a "factory" is something that gives you something else with certain characteristics.
So suppose you have a bunch of "Car" classes, you need a "redCar" and a "blueCar" and a "greenCar" etc.. and the list goes on. So instead you could have a "car factory" that spits out a car with the characteristics that you want. So you'd have "blah blah = carFactory("red");".
So whenever you want a red car you just create a car factory that produces red cars and grab your cars from it (instead of separately creating car classes with different attributes).
Adapter: This is a bit more tricky, but again you can't go wrong with what the name implies, it's a class/thing that adapts something to something else.
It's useful when you want to "bridge" a gap between one thing and a bunch of other things.
You would have a bunch of adapters that consume the same kind of data and translate that to something else that the other end is expecting (just like a VGA to HDMI adapter that adapts VGA signal to HDMI).
Abstract: abstract something means the something itself is not "complete" or stand-alone, it needs something else to complete it, or to make it "concrete" as they say.
An abstract thing, defines the common denominator between the things of the same kind.
So an "AbstractCar" could have "startEngine()", "stopEngine()", "honkHorn()" and "moveForward()" methods because we expect all our cars to have those things, "honkHorn()" could be already implemented because we happen to use the exact horn system in all cars so it would be a "concrete method" but "startEngine()" would need to be implemented specifically for each car, so "how to start the engine" is not something that can be shared amongst the cars, it will remain an "abstract method" that needs to be implemented by each type of car to account for the differences they have.
So where were we? "AbstractAdapterFactory", reading from right to left, we know whatever it is, it's a "factory" so we tell it some stuff about what we want, and like a factory it will create the thing that we asked it to create.
Then we see "adapter" so far we know we have a "AdapterFactory" so we know it can give us adapters of certain kind, for example 'blah blah = new AdapterFactory("VGA", "HDMI");'.
But then we see "Abstract" so now we know we have an "AdapterFactory" that happens to be "Abstract" too, or a "AbstractAdapterFactory".
Which means it's a generic AdapterFactory, depending on what kind of AdapterFactory that we want, we have to create a more specific one, which will no longer be "abstract".
So for example we could create a concrete "VideoCableAdapterFactory" from "AbstractAdapterFactory".
But just as well we could create a concrete "ElectricSocketAdapterFactory".
So you can see it's powerful but also easily abused when overdone. I'm no fan of it.
I hope that verbose explanation helps someone else who may have become lost in the big words and mumbo jumbo.
I'm not even a Java developer but I understand it quite well.
I'll have a go at explaining it with simple ideas.
So let's break it down (from right to left):
Factory: as the name implies a "factory" is something that gives you something else with certain characteristics.
So suppose you have a bunch of "Car" classes, you need a "redCar" and a "blueCar" and a "greenCar" etc.. and the list goes on. So instead you could have a "car factory" that spits out a car with the characteristics that you want. So you'd have "blah blah = carFactory("red");".
So whenever you want a red car you just create a car factory that produces red cars and grab your cars from it (instead of separately creating car classes with different attributes).
Adapter: This is a bit more tricky, but again you can't go wrong with what the name implies, it's a class/thing that adapts something to something else.
It's useful when you want to "bridge" a gap between one thing and a bunch of other things.
You would have a bunch of adapters that consume the same kind of data and translate that to something else that the other end is expecting (just like a VGA to HDMI adapter that adapts VGA signal to HDMI).
Abstract: abstract something means the something itself is not "complete" or stand-alone, it needs something else to complete it, or to make it "concrete" as they say.
An abstract thing, defines the common denominator between the things of the same kind.
So an "AbstractCar" could have "startEngine()", "stopEngine()", "honkHorn()" and "moveForward()" methods because we expect all our cars to have those things, "honkHorn()" could be already implemented because we happen to use the exact horn system in all cars so it would be a "concrete method" but "startEngine()" would need to be implemented specifically for each car, so "how to start the engine" is not something that can be shared amongst the cars, it will remain an "abstract method" that needs to be implemented by each type of car to account for the differences they have.
So where were we? "AbstractAdapterFactory", reading from right to left, we know whatever it is, it's a "factory" so we tell it some stuff about what we want, and like a factory it will create the thing that we asked it to create.
Then we see "adapter" so far we know we have a "AdapterFactory" so we know it can give us adapters of certain kind, for example 'blah blah = new AdapterFactory("VGA", "HDMI");'.
But then we see "Abstract" so now we know we have an "AdapterFactory" that happens to be "Abstract" too, or a "AbstractAdapterFactory".
Which means it's a generic AdapterFactory, depending on what kind of AdapterFactory that we want, we have to create a more specific one, which will no longer be "abstract".
So for example we could create a concrete "VideoCableAdapterFactory" from "AbstractAdapterFactory".
But just as well we could create a concrete "ElectricSocketAdapterFactory".
So you can see it's powerful but also easily abused when overdone. I'm no fan of it.
I hope that verbose explanation helps someone else who may have become lost in the big words and mumbo jumbo.
What I could gather from the wikipedia entry on the "Adapter Pattern"[0] is that an Adapter is a wrapper class that conforms to a different interface than the class that it is wrapping.
For example, class A implements foo(), but you want it to conform to interface B which requires that you implement bar(). So you make an "Adapter" which implements bar() by calling foo().
This is probably oversimplifying but conceptually it's like a USB to serial adapter. Provide the same functionality through a different interface.
An AdapterFactory might automatically create an Adapter between two classes?
As for an AbstractAdapterFactory, you might have a couple different AdapterFactories and you want some shared functionality between them. Same reasons you'd make any class abstract.
That's all speculation though, I've never actually coded with an "Adapter" before.
[0] http://en.wikipedia.org/wiki/Adapter_pattern
For example, class A implements foo(), but you want it to conform to interface B which requires that you implement bar(). So you make an "Adapter" which implements bar() by calling foo().
This is probably oversimplifying but conceptually it's like a USB to serial adapter. Provide the same functionality through a different interface.
An AdapterFactory might automatically create an Adapter between two classes?
As for an AbstractAdapterFactory, you might have a couple different AdapterFactories and you want some shared functionality between them. Same reasons you'd make any class abstract.
That's all speculation though, I've never actually coded with an "Adapter" before.
[0] http://en.wikipedia.org/wiki/Adapter_pattern
I think the point was to be a little surprised that Python is also very high on that list.