3 ms·
In my job I do a lot of code review of client code, mostly in Java, and some of it is particularly terrible. In fact, there’s one problem I see that is endemic.
by dkarl 6y ago
In my job I do a lot of code review of client code, mostly in Java, and some of it is particularly terrible. In fact, there’s one problem I see that is endemic. That’s where the code is “supposedly” object-oriented, but in fact, it doesn’t take advantage of any of the features of object orientation (no inheritance, no method overrides, and few if any uses of type substitution). In particular I see tons of code where there are these static “data” objects (a misunderstanding of another pattern from Martin Fowler, called the Data Access Object) and these “processing” objects that are, for the most part, just bags of procedures that operate on the data objects.
The author really loses me here. I cut my professional teeth on Java, read Design Patterns while I was working my first job, and wrote his preferred style of OO code for years. I still use those OO features in my code, because they're still useful for a lot of things, but over the years I've learned other techniques as well that have helped me make my code simpler to understand and maintain.
In the early 2000s I did see bad C-style Java written by people who didn't yet know how OO could be used for good, and if the author had written this in 2000 or even 2010 I could give them the benefit of the doubt that that's what they're complaining about, but if the author is seeing Java code in 2020 that they think isn't OO enough, it isn't because people don't know the style. It's because they know there are different choices that can often produce better results. I still run into people in real life who criticize code for not being written in that old 1990s/early 2000s style, for tackling problems with techniques other than inheritance and polymorphism, for daring to have data without behavior, etc. If you're satisfied with that old style and want to spend the rest of your career solving problems with it -- fine. But when other people move on, don't criticize them as if they haven't caught up.
- ncmncm 6y agoYes, it is ridiculous to criticize Java coders for "misusing" their OO mechanisms. Those mechanisms are all they have, to build everything, whether OO makes sense in that niche or doesn't. So, probably more often than not, they are obliged to cobble together a substitute for what they need from the limited toolkit at hand, making a hammer do a screwdriver's job, as best they can. You have to feel sorry for them, and even sometimes admire them, making the best of adversity in their impoverished language. Then think of the poor C coders, lacking even that.
- dkarl 6y agoIn the current-day context there are a lot of ways you can improve Java code just by not using OO mechanisms. A lot of the pervasive use of inheritance in the past was driven by the assumption of working in big monolithic codebases in huge teams with long development cycles and really poor use of SCM. Working in small teams, on microservice codebases, in short dev cycles, without long-lived feature branches and late merges, you don't need as much protection against other people's code. You can use concrete classes instead of interfaces, and you can separate data from algorithms instead of finding ways to conceptualize every function as a "behavior" of some anthropomorphized collection of data. A couple of edits: The old style makes sense for the API surface of libraries; I won't dispute that. As much as they annoy me, I do see a bright side to people who insist on defining "correct" Java style as the circa-2000 style motivated by a bunch of long-dead assumptions: they will help Java die. Nobody under forty wants to write code that way. All it will take to kill Java will be for Oracle to declare a future release (say Java 25) as an "eternal support" release and then release an entirely different language as "Java 26" the way Microsoft did with Visual Basic.