2 ms·
That's pretty funny, but EventFactoryFactoryFactory isn't exactly Java's fault. There's a software development culture that believes adding a layer of abstract
by jmull 9y ago
That's pretty funny, but EventFactoryFactoryFactory isn't exactly Java's fault.
There's a software development culture that believes adding a layer of abstraction is the answer (doesn't matter what the problem is) as long as it has a GoF pattern name (doesn't even need the implement the pattern its named for).
For whatever reason they've adopted Java, but if you're going to throw abstractions on top of abstractions carelessly you're going to create a mess of spaghetti no matter the language or environment.
(I think the preference for Java is just an accident of timing of when the culture arose. The responsibilities of corporate IT groups were exploding and they needed a language for all the software they had to create. Java was there and it was a good choice.)
I'm feeling bad about my laughing and complaining, which is useless, so here's some practical advice on restraint when it comes to using abstractions and patterns:
* Don't use an abstraction to wrap something you don't understand well. You may feel like you've tamed a confusing, complicated API and turned it into something you do understand and can use effectively. But you've actually just rolled up all the things to didn't account for and don't understand and hidden them away from view where they will explode if your software actually sees much use. I realize this isn't always easy to avoid doing, but at least never wrap something in an abstraction because you don't understand it that well. And when you're forced to implement an abstraction on top of an API you don't understand well, go through the API, method (or function or endpoint or whatever) by method, and look at all the options and ask yourself what each of those options and methods are there for.
* When considering using a pattern, make sure to check the section titled something like "When Does This Pattern Apply?" and make sure the abstraction you're considering actually solves the problem.
- geodel 9y agoI 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.
- jmull 9y agoI should clarify: I don't have a problem with the factory pattern. I have a problem with piling abstractions and indirection on top of abstractions and indirection to create spaghetti systems. I don't know how EventFactoryFactoryFactory is being used but it looks like we're dealing with four levels of abstraction simultaneously, which seem likely to me to be a horrible failure of design. (I'm kind of assuming this isn't an event planning system, or something, and that "event" is an abstraction for something happening.)