5 ms·

If you have a mutable class, and you're modifying its fields, you're doing it for a reason, right? Often it's part of a larger operation. So why not name the me

If you have a mutable class, and you're modifying its fields, you're doing it for a reason, right? Often it's part of a larger operation. So why not name the method that mutates the field after that reason. I got away from thinking about "I am altering the internal representation of this struct + vtable" to "I am sending a message to this opaque thing and I don't really care how it's done when I'm outside the black box". > but "setters are always bad and i don't understand why anyone would ever use them" seems like a needlessly hard-line sentiment, IMO. I have a strong opinion because I read some compelling arguments, thought about a lot, stopped using setters, and the quality of my code improved. I don't see a need to moderate my opinions on programming, especially when that's what I really think. Again, happy to be shown a great counter example and admit I was wrong.

wvenable 9y ago
This seems to deny the fact that a lot of data exists to just be stored and displayed. Probably 85% of all software in the world has a "FirstName" field/property/column in it somewhere. What name you propose giving a method that changes that value?
- HumanDrivenDev 9y ago
  I guess I'd call it "changeLastName". That's closer to the domain, we don't go to the Department of Births, Deaths and Marriage and tell the clerk we want to "set" our last name. But that is being too pedantic, even for me. I'll concede defeat. That is a pretty good example. At the end of the day, "customer details" class is actually a big bag of fields that needs some access control and validation.
  - wvenable 9y ago
    If you get married, you might "changeLastName" or maybe even "rename" yourself but if you're just moving that name from one place to another you'd "set" it. You could probably come up with lots of different names but none of them will be more clear than "set" in this case.
    - usrusr 9y ago
      If moving requires a name to be set you are at constructor time, no need for permanently available setters.
      - wvenable 9y ago
        Two things with that, you're assuming immutability but even a simple database entity object wouldn't be immutable. And secondly, anything over a handful of values and setting them via a constructor isn't pretty.
- abiox 9y ago
  if it's just used for display, use a new value. if there's more to the domain context, i'd call it rename(~). i think from the outside, it's better to articulate what you want in domain semantics, rather than implementation semantics.
  - HumanDrivenDev 9y ago
    i think from the outside, it's better to articulate what you want in domain semantics, rather than implementation semantics. You've articulated here what I've actually been trying to communicate. I have no problem if a method does nothing but get/set a variable. I just think they should be named with domain semantics.
arthur_pryor 9y ago
> If you have a mutable class, and you're modifying its fields, you're doing it for a reason, right? Often it's part of a larger operation. So why not name the method that mutates the field after that reason. I got away from thinking about "I am altering the internal representation of this struct + vtable" to "I am sending a message to this opaque thing and I don't really care how it's done when I'm outside the black box". > > but "setters are always bad and i don't understand why anyone would ever use them" seems like a needlessly hard-line sentiment, IMO. > I have a strong opinion because I read some compelling arguments, thought about a lot, stopped using setters, and the quality of my code improved. I don't see a need to moderate my opinions on programming, especially when that's what I really think. Again, happy to be shown a great counter example and admit I was wrong. that's all fair. i think we might actually agree more than disagree. all your arguments are compelling, and i could see myself holding a similar opinion after giving the matter more thought.

wvenable 9y ago

This seems to deny the fact that a lot of data exists to just be stored and displayed. Probably 85% of all software in the world has a "FirstName" field/property/column in it somewhere. What name you propose giving a method that changes that value?

HumanDrivenDev 9y ago
I guess I'd call it "changeLastName". That's closer to the domain, we don't go to the Department of Births, Deaths and Marriage and tell the clerk we want to "set" our last name. But that is being too pedantic, even for me. I'll concede defeat. That is a pretty good example. At the end of the day, "customer details" class is actually a big bag of fields that needs some access control and validation.
- wvenable 9y ago
  If you get married, you might "changeLastName" or maybe even "rename" yourself but if you're just moving that name from one place to another you'd "set" it. You could probably come up with lots of different names but none of them will be more clear than "set" in this case.
  - usrusr 9y ago
    If moving requires a name to be set you are at constructor time, no need for permanently available setters.
    - wvenable 9y ago
      Two things with that, you're assuming immutability but even a simple database entity object wouldn't be immutable. And secondly, anything over a handful of values and setting them via a constructor isn't pretty.
abiox 9y ago
if it's just used for display, use a new value. if there's more to the domain context, i'd call it rename(~). i think from the outside, it's better to articulate what you want in domain semantics, rather than implementation semantics.
- HumanDrivenDev 9y ago
  i think from the outside, it's better to articulate what you want in domain semantics, rather than implementation semantics. You've articulated here what I've actually been trying to communicate. I have no problem if a method does nothing but get/set a variable. I just think they should be named with domain semantics.

arthur_pryor 9y ago

> If you have a mutable class, and you're modifying its fields, you're doing it for a reason, right? Often it's part of a larger operation. So why not name the method that mutates the field after that reason. I got away from thinking about "I am altering the internal representation of this struct + vtable" to "I am sending a message to this opaque thing and I don't really care how it's done when I'm outside the black box". > > but "setters are always bad and i don't understand why anyone would ever use them" seems like a needlessly hard-line sentiment, IMO. > I have a strong opinion because I read some compelling arguments, thought about a lot, stopped using setters, and the quality of my code improved. I don't see a need to moderate my opinions on programming, especially when that's what I really think. Again, happy to be shown a great counter example and admit I was wrong. that's all fair. i think we might actually agree more than disagree. all your arguments are compelling, and i could see myself holding a similar opinion after giving the matter more thought.