4 ms·

Historical reasons. Back then it was all about hiding state which was perceived as some hidden walled paradise where there are no rules and yet everybody lived

by usrusr 4y ago

Historical reasons. Back then it was all about hiding state which was perceived as some hidden walled paradise where there are no rules and yet everybody lived happy and without strife. Some certainly saw the need for dependable rules and so on (after all you can have final fields and be forced to set them in the constructor) but the lure of easy attitude from true believers was so strong that The Bean became the de-facto standard for about a decade. The Bean, with its sole default constructor giving a heartfelt middle finger to everything resembling some kind of predictability. It was a painful learning process from there to where we are now, where we consider any internal state that isn't passed to the constructor in an already immutable shape a considerable smell that you'd better have very good reasons for and we prefer a clear distinction of preparation and operation phases separated by that one constructor which sets (and in most post-OOP languages also declares) the values of the object's constituents. (PS why isn't "post-OOP" a far more established term? It feels considerably more useful to me than the usual mind gymnastics about "functional but not quite" that provoke all those (im)purity squabbles that help noone)

imtringued 4y ago
"The Bean" is mostly a framework compatibility thing. For example, Hibernate needs to be able to proxy your type and cannot intercept member variables. So now you need getters and setters.
- usrusr 4y ago
  Not the least interesting subchapter of the bean story, because those things were the most pressing oop data + behavior conglomerates that desperately needed disentanglement, and because "truth from the backend" is one of the most obvious use cases for immutability. But The Bean was more than that, just think of that FactoryFactoryBean meme that haunts Java to this day which was (in my perception) the result of that misguided love affair with XML called the XmlApplicationContext. ("who needs a compiler when we have xsd to ensure footgun correctness!")

by usrusr 4y ago

imtringued 4y ago

"The Bean" is mostly a framework compatibility thing. For example, Hibernate needs to be able to proxy your type and cannot intercept member variables. So now you need getters and setters.

usrusr 4y ago
Not the least interesting subchapter of the bean story, because those things were the most pressing oop data + behavior conglomerates that desperately needed disentanglement, and because "truth from the backend" is one of the most obvious use cases for immutability. But The Bean was more than that, just think of that FactoryFactoryBean meme that haunts Java to this day which was (in my perception) the result of that misguided love affair with XML called the XmlApplicationContext. ("who needs a compiler when we have xsd to ensure footgun correctness!")