[kalak451]

The getter/setter stuff in java is a huge waste of space and time. However, at least in the enterprise space, all of the tooling and frameworks assume your code follows the java bean naming conventions. For this reason alone I always make sure all my classes follow the pattern and whenever I train new developers I make sure they get a large amount of experience building out bean definitions and understand how much time is saved with Spring and Hibernate as long as the conventions are followed.

But yeah, its a bunch of ridicules, generated spam.

[pigs]

Joshua Bloch in Effective Java argues that the java bean is an anti-pattern and should be avoided.

[Roboprog]

Oh thank God somebody in authority is calling this bean bull_hit what it is.

After reading the Eiffel book and thinking about things like programming by contract and class invariants, the bean pattern which constructs empty, initially useless (or at least unreliable) objects seemed like a huge step back.

[figglesonrails]

Cool story, bro.

(Mime aside, do we get to hear what the argument was?)

[pigs]

The crux of the argument (and most of the book for that matter) is that you want to avoid mutability whenever possible. Adding setters for every field by default means mutability is the default mode for your application. Adding getters for every field by default means you lose any advantages of encapsulation. At one time, Java Beans were a heavily marketed pattern by Sun. Joshua Bloch came along and said "hey, this is a bad pattern" (and maybe others, but he's the one I always think of).

[jiggy2011]

Why does everything have a getter/setter by default? That is a pretty horrible anti-pattern, is it something to do with being able to serialise the state (including internal state) of the whole object?

[hackinthebochs]

It's about hiding implementation. If you access an object only through methods then the implementation can change without the client code having to know or care (aka be recompiled)