Well, a factory pattern is a well-defined pattern in OO software design, and one that a developer of any experience level can look up and understand. Your particular implementation may give rise to a more plain and contextually-accurate name, but if you call it something other than a Factory, posterity may need more time and context to discern what your code does.

If I'm a new developer on a project, I know what a SprocketFactory does, and I know that I'm going to get SprocketFactorys from a SprocketFactoryFactory, and I know that if I call the SprocketFactoryFactoryFactory, I'm sure as hell gonna get back a SprocketFactoryFactory, which will then give me a SprocketFactory, which will then produce Sprockets.

If I'm a new developer on a project and see a class called "SprocketFactoryFactoryFactory" I'm probably going to cry for a bit and wonder whether I couldn't have got a better gig, and then try to figure out a better way of producing sprockets.

Human short-term memory only has a size limit of about 4 simultaneous chunks so once you're juggling those levels of indirection any development is going to be glacially slow until you've acquired a great deal of experience with the codebase.

Out of interest, can you describe a concrete case where multiple levels of factory patterns have actually been justified and resulted in simpler code than an alternative?

If Java had default parameters and named parameters I think a ton of the need for Builders and Factories would go away.

I can't, but if you're the FNG on a project and see SprocketFactoryFactoryFactory, you may have a quick and easy path to a better solution. Just make sure that that better solution names its patterns well so the next FNG can make your code even better.

I like how you assume that a mind that doesn't balk at "SprocketFactoryFactoryFactory" is also a mind that will ensure the implied contract of that name is adhered to. But I guess that sort of optimism -does- come with 'new developer on a project', so you're probably correct in what the developer will think they know.

I think between a horrible application of a pattern that has a good chance of being implemented properly and a horribly named class that leaves no potential to intuit its behavior, you might fare better with the former, as a new dev. But at that level it's all subjective.

"There are two hard problems in Computer Science: naming things, cache invalidation, and off by one errors"

People give up on the naming things because the name they're seeing makes sense to them in that moment and they may not realize how confused they'll be when they come back to the code in 3 months. May be a lack of experience in maintaining "old code" or just part of the programming culture they're in.

"Comments are for people other than yourself and that includes you because future you is not you"

I think a portion of it may be java's widespread use in large, "enterprise" environments where due to a variety of cultural and technical factors there's a high level of complexity and abstraction. Pretty soon it becomes the norm. I know plenty of java codebases that are clean, readable, and FactoryFactory-free, but never from an "enterprise" company.

>I don't know what it is about Java that makes people write code and name things like this.

The cause is lack of abstraction and a very limited(rigid, opposite of "flexible") object system. The programmer must use some specific design patterns as workaround and thus name classes according to the semantics of the pattern applied.

In OOP, a factory is a pretty common design pattern, and I'm a bit surprised you've never seen it in 15 years of software development... considering it's taught in schools these days. In a nutshell, a factory is a class who's purpose is to generate instances of other classes (https://en.wikipedia.org/wiki/Factory_method_pattern).

The main reason they're used is to create objects without specifying the class of the object, however there are plenty of other reasons why they're common as well.

You start stretching it when you have FactoryFactory. This presumably would be a factory that creates factories. If I saw this in a code review, I would call it out, as it could most likely be refactored to be simpler. FactoryFactoryFactory is beyond silly.

I think you misread the comment. The poster says that the classes did not have the word «factory» in the name. The functionality was the same.

I think a big part of it is that common libraries do it and ask you to do it more. Spring and Tomcat and etc are, imo, abominations of complexity -- but you still often find yourself buying into their ecosystems. Especially if you're working on code that's a few years old.

I'll add: both Spring and Tomcat exemplify this quality that a lot of earlier (2000-era) Java frameworks have (others: Hibernate, actually literally anything that embraces XML...), of being "extensible mostly in name only". You can, in theory, implement modules that tie into various parts of their functionality -- and in practice I've found myself doing it occasionally -- but it's almost always regrettable.

Anything you figure out how to do in these will itself just become un-figure-outable for the next engineer who handles it.

(One of the most frustrating tasks in my engineering career involved trying to debug why Spring beans loaded by a Spring-Tomcat integration layer, in the initialization of a Tomcat container, weren't discovering XML files loaded at another stage of initialization. When I look back on that year I think I might have indirectly changed jobs because of it. Hah.)