Re:Software Design Patterns Are Not Goals, They Are Tools
by mohaine on Thursday May 19, 2016 @09:12AM
(#11729873)
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.
Re:Software Design Patterns Are Not Goals, They Are Tools
by _asummers on Thursday May 19, 2016 @09:32AM
(#11730029)
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.
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.