I suppose you haven't seen much of the world of Enterprise Java Applications?

https://docs.spring.io/spring/docs/2.5.x/javadoc-api/org/spr...

Many years ago, I briefly worked in that industry and thoroughly hated the rigid, dogmatic, extreme overengineering culture and the resulting code it produced. I'm glad to be away from it all.

A few years back I worked on a project (by myself!) where I inherited an epic codebase that was basically the Enterprise Fizzbuzz application scaled up to ~30 person years of effort - it had tens of thousands of classes and a seeming desire to use every known feature of Enterprise Java and every Design Pattern - actually finding where stuff actually happened in the haystack of abstractions was quite entertaining.

https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

NB I have a strange definition of "entertaining" in a work context - I was contracting at the time.

Much of the Java+Patterns=<3 stuff came from java lacking syntax for functions that didn't involve creating an entire anonymous inner class with an apply function; the Strategy pattern is an excellent example of a pattern that just goes away when you can pass functions around. There just are not good ways to express certain solutions without using at least one or two, for any sufficiently large piece of software, without that syntax. And if your language is making what you're doing awkward, it's probably not how most people are going to code. Guava had an entire disclaimer in their functional documentation that essentially said "whenever you reach into this toolbox, think about if it's really what you want". Now that Java8 has syntax for them, we should see people reaching more for Streams and their functional methods.

Now, that said, it's often more tempting and easier to just add complexity, which results in crazy codebases. It's much harder, especially under pressure of deadlines, to REMOVE patterns as they don't make sense anymore, which gives us what people think of as enterprise Java. Not all Java is like that, I promise.

Sadly, it seems that most of the java devs who created these monstrosities learned the wrong lessons.

As far as I can tell they seem to think total lines of code was the real issue (It couldn't be the Abstractions/Patterns, those are good!) and are now on a kick to move as many lines of code as possible to annotations. I call this "Annotation based programming" and any new problem starts with a google search since how any tool kit handles something is pure guesswork.

If you're going to denounce annotations, you must also denounce decorators in both Python and Javascript. Annotations are a super powerful tool that get used too much. To borrow from Lisp: data > functions > macros. They should be the last tool you reach to, in order to remove a bunch of repetition with the intention of simplifying your code. "Could you do what you're trying to do with a library of functions that you simply call into? Or some sort of composition? Or maybe a parent class?" type questions should be asked before you reach for any sort of metaprogramming.

Take a look at the Retrofit library from Square for a good example of usage of annotations. To the original Spring link posted, while there's lots of annotations, they're replacing the XML that used to plague Spring projects, which I find much more magical. At least I can jump to an annotation's definition in my IDE.

Software design patterns as a goal are perfectly appropriate for APIs - the point is that if you use a well known pattern then programmers working against the API will be familiar with what's going on - if they're familiar with the pattern. If they're not familiar it gives them an opportunity to learn about it, rather than some messed up emergent rats-nest of functions just pulled out of the air.

Even if the functions you provide only loosely fit an established pattern it's still worth "adapting" with verbose notes about how it doesn't conform to said pattern.

Actually I would go so far as to say there is value in developing within a pattern even if you're not building an API, if you expect that a number of third parties may have to maintain or develop your code for years to come.

However, if you're working against problem domain that is well understood in your organisation (technically specialised, low level) it doesn't make sense to force a pattern upon it. It is reasonable to expect that third parties should know what's going on already.

I think the problem, however, is when your stack trace is too long for your scroll buffer, you've gone a little overboard.

Of course! Your software must be usable and maintainable. These should be your top priorities.

Oh, please give it a rest already. That Spring release is from 2007. Things have moved on.

On the other hand a lot of people judge C++ or Javascript by 90s standards. So first impressions stick for a long time :)

Let me just say thank you for picking that particular example.

Now please excuse me. I just discovered a new hammer and I'm sure as hell gonna hit something with it.

They still believe that they are tools. The goal is working software, they're just overusing design patterns.

The goal is "the one true architecture" that can handle any future change. It's BS and soooo many self proclaimed "architects" fall into it's trap.

Except that people (and I have done this earlier in my career) make a lot of uninformed assumptions about what future changes might actually be and then when an actual future change comes along it often turns out to be different from what was expected and everyone gets a deeply unpleasant surprise.

I once (maybe it's in different state now) looked at C++ boost package that was supposed to work with dates and times. It had immense number of classes (or methods or whatever) and was for my needs completely useless. The way I remember them, the most of the classes (or methods) were to provide "abstractions" but whoever designed "abstractions" designed them without having ever doing any non-trivial job with time and therefore the abstractions were in tons but nothing I could use. I had the similar impression for a lot of boost packages: an immense amount of red tape all around, but no "meat." But hey, also every imaginable C++ feature is used. Then I've discovered that Google at that time forbade developers using the whole boost and I've felt a bit better.

That's honestly sounds like FUD. The Boost community has rejected OO design and abstractions from the very beginning embracing the STL design instead.

Dates and times is a complex problem, you won't find a simple solution for it. For the record boost.date_time ony has concrete classes and no abstractions. It barely uses templates.

"Then I've discovered that Google at that time forbade developers using the whole boost"

Their loss.

I haven't checked recently, at that time the classes didn't support the historical time zone calculations. I've looked at a lot of code (yes, they were not hierarchical classes, but there was a lot of code) but there were really only the most trivial things supported.

And I admit, I never liked Boost, I am biased. But that doesn't mean that I'm misrepresenting how little what it had matched my needs, and the "bloat" feeling I've (and obviously Google too then) had.

Not sure what you mean by historical time zones. If you are referring to DST rules, boost.Date_Time released in Boost 1.34, which was released almost 10 years ago has a member function dst_local_start_time(year) for a time_zone object which returns 'The date and time daylight savings time begins in given year'.

The doc links for older releases seem to be broken on boost.org, so I can't check if the functionality is even older.

I agree. It should be obvious. I don't know anyone who believes design patterns are the goals.

Umm... he believed it, hence why he wrote about the insight he gained regarding this belief. And if he believed it, then there will no doubt be others like himself that believed it as well, and will benefit from this insight he has shared. Any insight like this that is shared with an intent to help others is valuable. It doesn't matter how simplistic or obvious we may think it is as there will be others out there that will learn from it. When we make statements like this, we discourage others from sharing things they have learn't in fear of being judged as not knowing something that should 'supposedly' be obvious.

Well, the author says that he had been an advocate and even educator on design patterns, yet also admitted that he has never read the definitive (GoF) work on the subject. IIRC, the book's preface declares the very thing the author "discovered" for himself and thought to share.

If you started reading the book, and gave up after 2 minutes, you would still have learned this lesson. So, yes, it shouldn't have to be said.

I'm inclined to believe that there are many that have not read the book and yet have tried to use the patterns mentioned in them. They would benefit from hearing what he has to say and why shouldn't they? Should they be punished for not reading the book by having all insights from one like them silenced? Have you also read every book that defines your craft? I don't think so. So wouldn't you then benefit from insight being shared that you missed because you did not read the book yourself? If the rule for sharing content was that you had to read every book on the matter first, then no one would be able to share anything. The point I'm simply making is that as long as there are those that will benefit from what you have to share, then its beneficial for you to share it regardless of how supposedly 'simplistic' or 'obvious' it is and mocking others for sharing things that we deem as obvious doesn't help anyone. Rather, it prevents others from learning. On the other hand, sharing something that is obvious to some but not to others, at least helps those that it wasn't obvious to. The guy did a good think by taking his time to collect his learnings and share it with others in the hope of helping someone else out there, only to be told that what he shared was obvious and so he shouldn't have said it. The price you pay for trying to help.