3 ms·

> Good Java should resemble C If that sentence from the article is the only thing you took issue with, I'd wager you interpret it different than the author's i

by treve 6y ago

> Good Java should resemble C If that sentence from the article is the only thing you took issue with, I'd wager you interpret it different than the author's intent. I took it as low on abstractions and mostly imperative.

brundolf 6y ago
It wasn't the only sentence I took issue with, it was just the one that raised my eyebrows the highest. > low on abstractions I feel with this that the author is going to the opposite extreme. The takeaway isn't that abstractions should be eliminated categorically, just that they have a cost and shouldn't be fetishized. > mostly imperative I take issue with this too, though this part may be more a matter of personal preference. Yes, it's worse when your imperative logic is split across 15 files, but I see imperative logic itself as something to be done sparingly. Imperative logic means mutation of state, means easy-to-lose-track-of side-effects, means unpredictable behavior. This is sometimes unavoidable at the systems level (where C is typically used), but it is absolutely avoidable at the application layer (where Java is typically used). Here's another one that raised a red flag: > A well-considered class...should be easy to name, ideally with a noun that corresponds to something in the real world with a lifecycle of its own. Real-world-modeling was found a long time ago to be a bad approach to OOP. The author is right to say that classes should represent clearly distinct concepts that are easy to name, but there's no reason those concepts also need to map to real-world entities. Often, they shouldn't.
- JamesBarney 6y ago
  >means unpredictable behavior There is something to be said about making sure it's clear where and when state mutates. But functional code has it's own set of pitfalls. I've seen otherwise good devs struggle like crazy reasoning about complex functional code. (Especially when it comes to performance) > Real-world-modeling was found a long time ago to be a bad approach to OOP. The author is right to say that classes should represent clearly distinct concepts that are easy to name, but there's no reason those concepts also need to map to real-world entities. Often, they shouldn't. I 100% disagree with this. Most applications are modeling domain logic and business processes as code. And ideally as many of your classes as possible refer to a concept or should translate to simple and understandable objects in your domain. In an ideal world every class would be named after a concept/entity your domain expert understands and uses. *Unless you read real world objects as physical objects, but I think the author meant real world as in domain concepts.
commandlinefan 6y ago
Yeah, from the title, I initially agreed with him, but although he's definitely right that over-abstraction leads to some horribly painful Java code, he seems to be arguing in favor of the other extreme: an abomination that I've been seeing more and more of in the past five or six years where nothing is a class unless it absolutely has to be (i.e. when unmarshalling XML or JSON or reading data from an ORM). In Java, this means that everything is declared static, including data. And in a horrible, unholy way, it does resemble C, right down to the non-thread-safety.

by treve 6y ago

brundolf 6y ago

It wasn't the only sentence I took issue with, it was just the one that raised my eyebrows the highest. > low on abstractions I feel with this that the author is going to the opposite extreme. The takeaway isn't that abstractions should be eliminated categorically, just that they have a cost and shouldn't be fetishized. > mostly imperative I take issue with this too, though this part may be more a matter of personal preference. Yes, it's worse when your imperative logic is split across 15 files, but I see imperative logic itself as something to be done sparingly. Imperative logic means mutation of state, means easy-to-lose-track-of side-effects, means unpredictable behavior. This is sometimes unavoidable at the systems level (where C is typically used), but it is absolutely avoidable at the application layer (where Java is typically used). Here's another one that raised a red flag: > A well-considered class...should be easy to name, ideally with a noun that corresponds to something in the real world with a lifecycle of its own. Real-world-modeling was found a long time ago to be a bad approach to OOP. The author is right to say that classes should represent clearly distinct concepts that are easy to name, but there's no reason those concepts also need to map to real-world entities. Often, they shouldn't.

JamesBarney 6y ago
>means unpredictable behavior There is something to be said about making sure it's clear where and when state mutates. But functional code has it's own set of pitfalls. I've seen otherwise good devs struggle like crazy reasoning about complex functional code. (Especially when it comes to performance) > Real-world-modeling was found a long time ago to be a bad approach to OOP. The author is right to say that classes should represent clearly distinct concepts that are easy to name, but there's no reason those concepts also need to map to real-world entities. Often, they shouldn't. I 100% disagree with this. Most applications are modeling domain logic and business processes as code. And ideally as many of your classes as possible refer to a concept or should translate to simple and understandable objects in your domain. In an ideal world every class would be named after a concept/entity your domain expert understands and uses. *Unless you read real world objects as physical objects, but I think the author meant real world as in domain concepts.

commandlinefan 6y ago

Yeah, from the title, I initially agreed with him, but although he's definitely right that over-abstraction leads to some horribly painful Java code, he seems to be arguing in favor of the other extreme: an abomination that I've been seeing more and more of in the past five or six years where nothing is a class unless it absolutely has to be (i.e. when unmarshalling XML or JSON or reading data from an ORM). In Java, this means that everything is declared static, including data. And in a horrible, unholy way, it does resemble C, right down to the non-thread-safety.