

Guess which language overuses AbstractAdapterFactory - xvirk
https://github.com/search?l=&q=AbstractAdapterFactory&ref=advsearch&type=Code&utf8=%E2%9C%93

======
jlund3
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...](http://adambard.com/blog/top-github-languages-for-2013-so-far/) to
[http://www.tiobe.com/index.php/content/paperinfo/tpci/index....](http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)
and notice the discrepancies. In other words, sampling on GitHub is severly
biased.

~~~
rch
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_.

------
delluminatus
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.

------
chmullig
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=Code&ref=searchresults)

~~~
eudox
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.

~~~
betacat
So, what is a better language for learning? (Genuinely curious.)

~~~
pokpokpok
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

------
bunderbunder
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...](http://www.bestbuy.com/site/travel-accessories/travel-converters-
adapters/)

[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
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
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.

------
ryandrake
Reminds me of: TransactionAwarePersistenceManagerFactoryProxy

[http://stackoverflow.com/questions/14636178/unsure-if-i-
unde...](http://stackoverflow.com/questions/14636178/unsure-if-i-understand-
transactionawarepersistencemanagerfactoryproxy/)

------
solomatov
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.

------
Igglyboo
Without even know what an AbstractAdapterFactory is I guessed Java. Can
someone explain what it is?

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

~~~
tptacek
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/)

------
tel
I think the point was to be a little surprised that Python is also very high
on that list.

