3 ms·
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
by borplk 12y ago
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.