5 ms·

In modern Java, one uses things like dependency injection (Guice, Spring, whatever) for building up the services, and I find most programmers now abhor setters

In modern Java, one uses things like dependency injection (Guice, Spring, whatever) for building up the services, and I find most programmers now abhor setters for their POJOs. Want a new Person object with a different name? Make a new one, it'll be okay, except in the most extreme of circumstances. Ephemeral memory is cheap. When an object comes back from a constructor, it should (in my mind at least) be immediately usable. People also enjoy the builder pattern, I've found. When you call .build(), it will do the internal checks to say if you screwed up, so you're guaranteed to never have a Person with no Organs. This is, of course a run time check so less helpful than a compiler error. Depending on the use case, it makes perfect sense, though. Also side note, how do I do the code blocks in HN comments like you did?

bencoder 11y ago
There's still a lot of getters everywhere though, which seemed to me to be the bulk of the analogy. this.wallet = colleague.getWallet(); Code blocks are done with 4 space indentation at the start
- reitanqild 11y ago
  Which is not a fault of the Java language: trainwrecks (this->getThat()->getThose()-foreach(){ do stuff } is a general antipattern. The correct way is IMO: colleague.getMoney() which can easily be implemented in Java, PHP etc. I'm getting a bit tired of this constant pecking at Java (nothing personal). There are a number of questionable designs yes, there is a lot of ugly code out there, yes, but almost every alternative might have been worse: Teaching everyone C? Good luck. Switch to C#? Until recently that would prevent you from using Linux on your servers unless you were ready to put in technical effort and bet on MS not suing you or the upstream effort. Perl? PHP? Catch my drift folks? Java filled a niche. It was almost as easy as PHP once you got started (although onboarding still is messy I think) and provided superior tooling.
  - woah 11y ago
    I think people just hate all the hoops you have to jump through to satisfy arbitrary constraints the language places upon you to conform to some pedantic definition of object orientation that only works well in textbook examples. Not saying Java isn't a good choice for some things. Also, if functional programming languages were more popular, they would probably be subjected to the same ridicule for the same reasons.
  - sevensor 11y ago
    By the same token, I think the superior tooling is part of the reason people who aren't primarily Java users find it incredibly painful. I've seen Eclipse experts in action -- most of the work seems to be picking the right thing from a drop-down. All kinds of things just appear where they're needed. Accustomed as I am to typing source code, I can't quite get my head around it.
  - bencoder 11y ago
    Despite the name, I didn't see the article as taking a pop specifically at Java. It seemed more about bad OOP in general. As you say, you'll see the same patterns in every OO language.
  - lmm 11y ago
    The story is explicitly about a bad citizen in Javaland.
  - workitout 11y ago
    >> Which is not a fault of the Java language: trainwrecks (this->getThat()->getThose()-foreach(){ do stuff } is a general antipattern. While I agree with you, isn't that what the new streams in Java does? The map reduce complex?
- steveklabnik 11y ago
  you only need two spaces, actually https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc
lmm 11y ago
Relying on dependency injection is even worse than setters. Will DI behave the same in tests as in real code? Are you sure? The right thing is to use an actual constructor that takes constructor parameters. Guice and Spring can both handle this correctly (you just put the @Autowired on the constructor itself). The trouble is that in Java this requires ~twice as many lines as putting a magic annotation on your fields.
- pbh101 11y ago
  Especially in the multi-core era, this becomes more and more important. Thanks to the Java Memory Model specification, if you are using constructors (and yes, pretty much every DI framework by now has this feature), with just a bit of care[1] you can ensure that your object is never visible to any threads without it having been completely constructed. [1] Make sure to not leak references to your object in your constructor. Most of the time that you would want to do this is starting a service or registering a handler, etc. The solution is to use a static creation method which first calls the constructor, and then registers/subscribes it, etc.

bencoder 11y ago

There's still a lot of getters everywhere though, which seemed to me to be the bulk of the analogy. this.wallet = colleague.getWallet(); Code blocks are done with 4 space indentation at the start

reitanqild 11y ago
Which is not a fault of the Java language: trainwrecks (this->getThat()->getThose()-foreach(){ do stuff } is a general antipattern. The correct way is IMO: colleague.getMoney() which can easily be implemented in Java, PHP etc. I'm getting a bit tired of this constant pecking at Java (nothing personal). There are a number of questionable designs yes, there is a lot of ugly code out there, yes, but almost every alternative might have been worse: Teaching everyone C? Good luck. Switch to C#? Until recently that would prevent you from using Linux on your servers unless you were ready to put in technical effort and bet on MS not suing you or the upstream effort. Perl? PHP? Catch my drift folks? Java filled a niche. It was almost as easy as PHP once you got started (although onboarding still is messy I think) and provided superior tooling.
- woah 11y ago
  I think people just hate all the hoops you have to jump through to satisfy arbitrary constraints the language places upon you to conform to some pedantic definition of object orientation that only works well in textbook examples. Not saying Java isn't a good choice for some things. Also, if functional programming languages were more popular, they would probably be subjected to the same ridicule for the same reasons.
- sevensor 11y ago
  By the same token, I think the superior tooling is part of the reason people who aren't primarily Java users find it incredibly painful. I've seen Eclipse experts in action -- most of the work seems to be picking the right thing from a drop-down. All kinds of things just appear where they're needed. Accustomed as I am to typing source code, I can't quite get my head around it.
- bencoder 11y ago
  Despite the name, I didn't see the article as taking a pop specifically at Java. It seemed more about bad OOP in general. As you say, you'll see the same patterns in every OO language.
- lmm 11y ago
  The story is explicitly about a bad citizen in Javaland.
- workitout 11y ago
  >> Which is not a fault of the Java language: trainwrecks (this->getThat()->getThose()-foreach(){ do stuff } is a general antipattern. While I agree with you, isn't that what the new streams in Java does? The map reduce complex?
steveklabnik 11y ago
you only need two spaces, actually https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc

lmm 11y ago

Relying on dependency injection is even worse than setters. Will DI behave the same in tests as in real code? Are you sure? The right thing is to use an actual constructor that takes constructor parameters. Guice and Spring can both handle this correctly (you just put the @Autowired on the constructor itself). The trouble is that in Java this requires ~twice as many lines as putting a magic annotation on your fields.

pbh101 11y ago
Especially in the multi-core era, this becomes more and more important. Thanks to the Java Memory Model specification, if you are using constructors (and yes, pretty much every DI framework by now has this feature), with just a bit of care[1] you can ensure that your object is never visible to any threads without it having been completely constructed. [1] Make sure to not leak references to your object in your constructor. Most of the time that you would want to do this is starting a service or registering a handler, etc. The solution is to use a static creation method which first calls the constructor, and then registers/subscribes it, etc.