Question

I have read some about the use of getters/setters in object oriented programming and many resources such as this suggest that they should be used very infrequently. A quote from that article says:

Don’t ask for the information you need to do the work; ask the object that has the information to do the work for you.

While that sounds good in principle, I’m not particularly sure how that is best implemented. Say taht I have a class the describes a car. Inside that class, lets say that the brand of this car stored in the class is “Toyota”. Now I have a GUI that wants to display that this is a “Toyota”. How does one do that without a getter?

Even if I abstract out that the “Toyota” is stored as a String and return a TextBox with “Toyota” already written in it, this sounds, at best, like a getter of a wrapped form of the original property. I just thought that things like TextBoxes should be only in the GUI’s class, and not in helper classes like my car class here.

Answer 1

You’re ignoring “to do the work”. If the work you want done is the brand of the car, then a getter that returns the brand does the work.

What the article is saying is if you want work done on class data, put the work in the class. Do not pull data out of the class, do work on it, then return it to the class:

var c = new Car();
c.Odometer += 10;  // bad
c.DriveMiles(10);  // good

I also question how applicable that article is to C#; it claims:

Getter and setter methods (also known as accessors) are dangerous for the same reason that public fields are dangerous: They provide external access to implementation details.

In C# this is false, a C# accessor can accept arbitrary classes, they do not “provide external access to implementation details”.