3 ms·
Having Getters for each member variable always seems fine and reasonable. It's when you have getters that do "magic" that I feel a little.. unsure. Like if it's
by takeawayandrun 11y ago
Having Getters for each member variable always seems fine and reasonable. It's when you have getters that do "magic" that I feel a little.. unsure. Like if it's taking a member and returning it in a different unit that seems kosher... But there is a fuzzy line where at some point the Getter is doing too much work to genuinely be a getter. It gives a false impression for the internal structure of the program. But conveying the const'ness is important as you describe (or semi-constness if you have caching)
- zeta0134 11y agoI'm of the somewhat unpopular opinion that "getters for everything!" is a philosophy that sounds good on paper, but results in writing a lot of getter and setter functions and feeling safe, while ignoring these sorts of traps cropping up everywhere. Member variables are easy to reason about; they behave exactly like the type they are, and in the case of built in types, have extremely consistent behavior. Getters / setters are a black box of mystery; I like to reserve that pattern for when there's going to be extra work to retrieve some value, so my call site knows it needs to tip-toe around possible failures. While I can see the value in using getters/setters for everything in something like an API or framework, I don't see the value in trying to use them all the time, "just in case."
- ta0967 11y agono, having getters for each member variable is a sign of pervasive action in distance and lifetime problems.