Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Some arguments in favour of getters and setters are; that using a function allows for the addition of caching, addition of thread safety checks, changing to compute the variable rather than store it, addition of logging, mapping it to be generated from another variable, etc.


All of these are usually made by theoretical purists. Meanwhile, the people who write the code see that most variables don't need any of the above, most of the time.


I understand all of those justifications. When I mentioned changing implementation in my post, I was thinking of exactly those sorts of things. But none of them seem to be applied in the general case of "make a pass-through getter and setter for every member variable". My biggest question to the answer of universal getter/setters is "what is being abstracted?" Classes (and objects) are meant to abstract things like an "engine" so that you don't have to twiddle fuel_injector_rate, spark_plug_timing, etc, but rather just call engine.startIgnition().


I tend to not mind using getters and setters, but I don't create one for every internal variable in a class. I consider "universal" getters and setters (which I take to mean one getter and setter for every variable in every class) to be an absurd idea, like something taken to the logical extreme just to piss someone off.

Perhaps a lot of people don't like using or writing getters and setters because it's cumbersome if the only code in them is an assignment/return statement. Maybe something like providing Ruby's attr_reader/attr_writer/attr_accessor to create these boilerplate getters and setters is what is required. Also in Ruby all member variables are private, so methods are always needed to access them.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: