4 ms·

It's not just java - any good OO platform has those problems. If you don't have that problem, it's worse: that tends to mean you failed to abstract away critic

by emn13 13y ago

It's not just java - any good OO platform has those problems. If you don't have that problem, it's worse: that tends to mean you failed to abstract away critical concepts like factories, and that you will have a hard time elsewhere, for example in testing (this is what you often see in C#, for instance) or with global state (a common issue in ruby code). There is of course an alternative: use a function rather than a factory; but that's kind of the point of this discussion :-). (Before we start a flame war: This isn't a criticsm of ruby or C# specifically, it's just something I've seen a lot in those code bases. Both languages allow writing factories or using lambdas.)

jkrems 13y ago
No, "any good OO platform has those problems" is just wrong. Point-like classes without factories or any other BS are alive in kicking in big code bases. And geometry (visualization) is actually an excellent example for where mutable state and simple classes make things easier (I can actually move the point/scene object and everyone who has a reference to it gets the update). I really hope those articles at some point will start being a little more balanced and stop trying to pretend like "the purer and functional the better" (or the opposite).
- emn13 13y ago
  I'm not suggesting that everything has a factory; I'm suggesting that having a factory isn't some java-specific code smell; it's a necessary pattern in an OO language. You obviously don't need one for a point. The context was some color picker example - and I could well imagine multiple color pickers and a useful color picker factory. And I entirely agree with you that a PointFactory is unwanted (barring special circumstances) - though I entire disagree you'd want points to be mutable. Certain control points? Certainly - make a MutablePoint which is (conceptually) simply a reference to a point value. All points? That's just asking for pain; I really have better things than to track down with nested submodule thought it was mutating a copy but due to some optimization interaction turned out to be mutating a copy someone was actually looking on. Not to mention that reference semantics don't work very nicely with hashtables and lots of other datastructures which become a lot more complicated when the values can change right under them.

by emn13 13y ago

jkrems 13y ago

No, "any good OO platform has those problems" is just wrong. Point-like classes without factories or any other BS are alive in kicking in big code bases. And geometry (visualization) is actually an excellent example for where mutable state and simple classes make things easier (I can actually move the point/scene object and everyone who has a reference to it gets the update). I really hope those articles at some point will start being a little more balanced and stop trying to pretend like "the purer and functional the better" (or the opposite).

emn13 13y ago
I'm not suggesting that everything has a factory; I'm suggesting that having a factory isn't some java-specific code smell; it's a necessary pattern in an OO language. You obviously don't need one for a point. The context was some color picker example - and I could well imagine multiple color pickers and a useful color picker factory. And I entirely agree with you that a PointFactory is unwanted (barring special circumstances) - though I entire disagree you'd want points to be mutable. Certain control points? Certainly - make a MutablePoint which is (conceptually) simply a reference to a point value. All points? That's just asking for pain; I really have better things than to track down with nested submodule thought it was mutating a copy but due to some optimization interaction turned out to be mutating a copy someone was actually looking on. Not to mention that reference semantics don't work very nicely with hashtables and lots of other datastructures which become a lot more complicated when the values can change right under them.