4 ms·
I don't think this kind of article is that helpful. There are aspects of a valid point in there, but it's buried and confused. That builder pattern makes me s
by jmull 2y ago
I don't think this kind of article is that helpful.
There are aspects of a valid point in there, but it's buried and confused.
That builder pattern makes me sick to my stomach.
Also, it starts with claiming state is part of the problem with getters/setters, but does not mention it again. (It seems to be conflating mutability and state, which, while often related in practice, are not necessarily that tightly coupled -- an immutable thing can nevertheless be state, and you can have mutability without introducing state. State is really about things that live beyond the immediate context/scope. So really nothing to do with getter/setter.)
- mrkeen 2y agoTell me about something which is mutable and non-stateful.
- jmull 2y agoI think you should take a minute to think about it. Let me turn it around on you: Give me a simple example in code of something that is mutable and not state. I'll come back later to check your answer and provide one of my own, if necessary.
- jmull 2y agoOK, here it is: int addOne(int value) { value += 1; return value; } value is clearly mutable, yet not state. State is a value you can refer to later. Here, "value" doesn't outlive the function, so can't be referred to later. State is a complication because you have to worry about whether it remains up-to-date. (Mutable state is even more complex because you also have to worry about if/when it may be changed.)