[lyudmil]

I don't pretend to know the answer to this, but I can share when I've been tempted to do such things in Java.

You know how fairly often when writing OO code you want to have an object that takes a bunch of optional inputs in its constructor? That's trivial in Ruby because you can just stick those in a hash, merge the defaults with that hash and you have your options. In Java that won't work because you don't have syntactic sugar for default arguments and the syntax for creating maps is... complex. So you naturally think you need one place to handle all of the complexity of constructing the object and then you think of the factory pattern and you apply it.

Imagine, though, that some of the objects you use in order to construct the object you now have a factory for also become similarly difficult to construct. You don't want your existing factory to know about the complexity of how to construct those, so one idea would naturally be to offload their construction to something else, which passes them into your original factory. It's not a huge leap to then figure out you can put this in another factory and now you have a factory of factories. Repeat.

I'm sure there are other reasons why, but for me that's the most common one. When I used to write a lot of Java, I used to often have to resist the temptation to do that.

I hope what I wrote makes at least a little bit of sense...