I don't think there's anything inevitable about AbstractSingletonProxyFactoryBean. This absurd design pattern has its roots in Java's misguidedly restrictive approach to abstraction, which all but requires classes and inheritance to be the primary units of abstraction. More graceful abstractions are unergonomic or impossible since Java was not designed e.g. for higher order functions. The requirement that everything be in a class and the ontological awkwardness that often ensues when some conceptually non-object-y entity must be coerced into an object results in a lot of incidental complexity.

> ontological awkwardness that often ensues when some conceptually non-object-y entity must be coerced into an object results in a lot of incidental complexity.

Is it really that hard to create a Helpers class with static methods?

I'm back on Java now after a rather long detour and I say I happily accept the verboseness of it for

- the niceness of having a IDE that can almost replace pair programming

- an ecosystem were dependency resolution works

> an ecosystem were dependency resolution works

My coffee just shot out my mouth.... What?

Java --> Diamond dependancies --> Install fickin' maven plugin to print dependency tree --> pray that clashing dependancies converge at some version combination, and that does not cause another issue in a different pair of dependancies (and that I don't have to rewrite my project too much).

I really like that nodejs can handle diamond dependancies.

sidenote: I do like the simplicity of Java code though too.

I think the real trick is avoiding trickery in the first place.

If you got yourself in a weird situation with Maven, either you have a seriously interesting project or you should admit you are probably doing something you shouldn't be doing and should take steps to fix it.

Just this week I've been cleaning up some old Java project and as often a major part of it has been to cut down the pom file by 50%.

It is now upgraded, faster and easier to understand and upgrade :-)

That’s just simply not true. Diamond dependencies are an all too common occurrence in java if you are writing anything serious. It doesn’t happen everyday but when it does it’s a serious PITA. It’s not a “you’re doing something wrong” but a “someone did something weird somewhere but now it’s up to you to solve”. You just pray it’s someone in your company who was the careless one.

Or you just have dependencies in your chain which require different versions of guava, or Jackson, or Lombok, or any of the other very common dependencies that still get changes

I disagree, there is nothing particularly different about "enterprise software" that requires a different naming scheme than other software. This is simply a cultural habit, and this cultural habit is supported by the fact that this same community uses IDEs that have good autocomplete feature. You can write enterprise software without naming your classes that long and be absolutely fine, and I argue this is not a trade-off it's merely a convention.

Enterprise software gets a lot of cargo-culted software patterns thrown into it, for better or worse. That's why you end up with names like that. The software design is convoluted, not the naming convention. The word Factory in WidgetFactory represents a software structure, not just the fact that it makes widgets. You're probably right that it's a cultural thing to use all those patterns though, but not for nothing.

I disagree that there's nothing different about enterprise software, the needs are inherently different to a product-owner/single-purpose software platform. By enterprise software, I really mean enterprise frameworks that are used across many projects and many teams. Patterns are simply a shared language of concepts. The need for strict structure so anyone can work on it or extend it without messing the whole thing up or introducing new concepts or legacy code is what drives the patterns.

You could absolutely build super simple large scale software without all those concepts, but then you get yourself a boutique app that only your team is familiar with. Which is fine for a single product owner platform, not fine for a framework with hundreds of devs working on it who all need to collaborate without ever talking to eachother.

Eh. Maybe not enterprise (it is extremely custom software for courts) but I was sold on the idea of DDD by someone who has to deal with one single word from the dictionary having 14 different meanings to the customer.

And since the wording is pretty much directly defined by laws and regulations you better get used to it since unlike in small businesses you cannot just argue with the product owner that these two mean the same.