Guess which language overuses AbstractAdapterFactory

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.

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.

Guess which language overuses the number 14763! https://github.com/search?utf8=%E2%9C%93&q=14763&type=Code&r...

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.

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

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

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.