A FactoryFactoryFactory in Production

I've personally seen the kind of engineers who simply pattern match rather than thinking things through go into nesting as many GoF chapters as they can into a commit. I was literally told during a code review when questioning what these layers were achieving for the product that 'all abstraction is a benefit since you can then always work at an even higher level'.

Java for whatever reason seems to attract these ideas.

Because nested factory patterns are a legacy of an era where lambdas were not well understood, or poorly represented by the type system

Continued use of Factory patterns doesn't deserve outright mockery, but does deserve immediate and firm correction. It introduced confusion and complexity and ontology to a place where a nullary lambda would do everything it does, and slice away all the ambiguity.

I don't really see why it matters what the motivation was behind it. The point is that Java for some reason seems to be an attractor for that kind of ridiculous code. It is where you end up when taking "OO design" to its logical conclusion. The OO paradigm is like religion: mostly harmless if you don't take it seriously.

I guess design patterns should never be applied. Those are simply optimal solutions to common design problems in OOP. When you encounter your own problem, derive your own optimal solution, and you call it some "pattern" if it happens to resemble one.

IMO pattern names are merely for communication purposes, like saying "abstract factory" instead of having to say "I have an interface F for creating instances of interface A, where different implementations of F can be chosen at runtime to create different instances of implementation of A". And also you are not required to call your factory "Factory".

I'm sorry but you can't possibly be serious. There is no sane motivation for a *FactoryFactoryFactory class. No problem on earth is complex enough to benefit from that much abstraction.

OOP has been a massive step in the wrong direction for programming. To take your example of DI, in Clojure, dependency injection can be done in a few lines for the whole application. In Java/C++/PHP and other languages that use constructor or setter injection, it requires all the code to be rewritten around a DI container, requires many modifications just to get to the point of writing code that actually does something. There is no comparison. We're talking a dozen lines of code vs. dozens of classes spread over dozens of files to achieve the same thing. Minutes vs. hours spend on boilerplate.

I wouldn't call this a knee-jerk reaction, but rather a well-thought out reaction to a few decades of OOP. When I started programming 25 years ago, I felt OO was a misguided idea but I was a novice and couldn't put my finger on it. Now, it's clear to me that all OO does is add unnecessary complexity and simply cannot model real life at all. I don't see a single problem that it solves better than either procedural or functional paradigms. Those paradigms have a lot less boilerplate, are a lot easier to understand, and can be learned much more easily.

Giving precedence to code over data, IMO, is a huge, irredeemable mistake. That's literally the mistake OOP is built on. Data should be a first class citizen in any system, yet it's a second or third class citizen in OOP. It is hidden in objects, processed only by limited certain methods, and generally hard to work with (you can have data only objects, of course, structs, but then you're back to a procedural paradigm). I find myself spending anywhere from 25-75% of my time in OOP languages writing boilerplate to get the right objects talking to each other and the rest writing actual business logic that matters. In something like Clojure, time spent writing boilerplate is around 5% at most. I'm using Clojure simply as one example. I'm sure there are other functional and procedural languages that are also good examples.

After reading this yesterday, I felt inspired to write a short article about how modern techniques deprecate the factory pattern (at least in the form GoF offers with specific ontology) and why composed lambda functions offer more functionality with less complexity.

http://extradimensional.space/posts/2017-12-18-Deindustriali...

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

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

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.

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.

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.

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.

It's a cultural issue.

Patterns are things you can avoid to use, they simplify a prior existing problem. But if engineers don't ask themselves what the code would look like if they wrote it differently, a lot of stupid code will be the result. That can be Boilerplate or it can be Spaghetti.

More communication within the team will help.

You see this a lot in C# projects that are ports from a Java analogue, like log4net.

C# often has "release valves" that allow you to divert from some of the mess that Java tends to exhibit. `events` and `delegates` from C# 1/.NET 1, flawed as they may be in retrospect, alone simplify several major patterns that Java falls into.

I also think on the paradigm issue here is Java architects seem more inclined to have a "ravioli code" problem. There's an ancient Java ideal of componentization [1] that a lot of Java code tries to live up to. Lots of little components boxed into tight containers that only ever interact through often "reconfigurable" sauce: ravioli.

There are some benefits to that ideal, it exists because it has some merits in terms of component testing, in particular. It's just that as with spaghetti code and copypasta code, ravioli code also sometimes winds up in a mess where the ideal meets the real world, and somehow a toddler (or junior developer in this analogy?) has thrown it all over the kitchen and you have no idea how to clean it up without destroying the entire kitchen and starting over... May not be a great analogy. ;)

I'd argue that you are more likely to see Java-style ravioli code in C# projects that use IoC containers of one sort or another. Again, there's nothing particularly wrong with IoC containers [2] as an idea connected to some ideals of component testing, it's just that it's an ideal that often falls down and fails to deliver its advantages in the real world.

[1] That somewhat resembles the Smalltalk ideal of object message passing while the language itself lacks much of the architecture for that. Arguably, a lot of Java's worst problems come from trying to replicate a lot of Smalltalk ideas and design patterns in a language that is nothing at all like Smalltalk and misses some important characteristics of Smalltalk.

[2] IoC Containers are a ravioli concept directly imported to C# from the Java world, with the earliest IoC containers such as Spring.NET being Java ports.

I look at JDK codebase it has about 360 factory classes. I look at popular Java project: Gradle, it has about 350 factories. My project at work has about 50 factories.

I agree that Factory* is not Java's fault. However I think Factory phenomenon did not start with corporate IT but by people working on core JDK or big open source projects.

I think most would agree FactoryFactoryFactorys are bad. But how does one fix this? What's the alternative? Maybe a post on how to disentangle one of these?

Let the past die. Kill it, if you have to.