3 ms·

Honest question: if constructors have these pitfalls, and using a different design pattern fixes the issue, why have constructors at all? Couldn't the whole iss

by saghm 4y ago

Honest question: if constructors have these pitfalls, and using a different design pattern fixes the issue, why have constructors at all? Couldn't the whole issue just be avoided by just having a basic, implicit constructor and then just letting people use static methods on top of this?

joshlemer 4y ago
Interesting question. Though, there's not really a factory method equivalent to super(). If you want your subclass factories to also call superclass factories to initialize parent state, you'd need to come up with an additional mechanism in user-space.
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!")
doctor_eval 4y ago
I think both the pitfalls of constructors and the benefits of factory methods are overstated. Go only supports factory methods, for example, and it’s probably the thing I like least about it. It makes dealing with default values in JSON really painful, for example. Being able to put an object into a specific well defined state at the time of instantiation is really good.
jayd16 4y ago
I think you misunderstood the solution. You still want constructors for safety during allocation. You just want to move non-allocation tasks out of the constructor because it adds some complexity to initializing instances that doesn't need to be there. Figuring out what to pass a constructor and the actual allocation are different tasks. The anti pattern is conflating them. It's fine to use constructors.

by saghm 4y ago

joshlemer 4y ago

Interesting question. Though, there's not really a factory method equivalent to super(). If you want your subclass factories to also call superclass factories to initialize parent state, you'd need to come up with an additional mechanism in user-space.

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!")

doctor_eval 4y ago

I think both the pitfalls of constructors and the benefits of factory methods are overstated. Go only supports factory methods, for example, and it’s probably the thing I like least about it. It makes dealing with default values in JSON really painful, for example. Being able to put an object into a specific well defined state at the time of instantiation is really good.

jayd16 4y ago

I think you misunderstood the solution. You still want constructors for safety during allocation. You just want to move non-allocation tasks out of the constructor because it adds some complexity to initializing instances that doesn't need to be there. Figuring out what to pass a constructor and the actual allocation are different tasks. The anti pattern is conflating them. It's fine to use constructors.