3 ms·

I'd call that "still a setter". I think the concern is that if bar is more about the representation of the object than the behavior, you're not operating at th

• scarface74 10y ago
  And the other alternative, because an object still usually needs some type of values would be: class Foo { Foo(string bar) { _bar = bar; } //Foo is the constructor } The benefit being that once an object is created, it is guaranteed to be in a valid state. But by classical OO an object represents state + behavior. So why not do both? Assign the value in the constructor to guarantee that the object is always in a valid state and use a property (if the object is an entity as opposed to a value object), when it needs to change?
  • lacampbell 10y ago
    Why is it changing? have the method name reflect that domain reason, not reflecting the mechanical details of which internal fields need to change.
• dragonwriter 10y ago
  The thing is, in simple cases the implementation will trivially parallel the sensible interface. So setters are appropriate. The problem becomes using setters where that's not the case, often to support tooling that is dependent on constructing objects from serialized state (which often also involves the same kind of abuse of getters, to which exactly the same concerns apply.)
  • dllthomas 10y ago
    To be clear, I wasn't endorsing the concern, just attempting to clarify it. It doesn't surprise me that it can be over-applied.