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