What's better practice? Protected / getter?

Question

If I have a class that inherits from another, and only this class has to use a certain variable, which is better practice? To have said variable be 'protected' in the base class, or have it private and give it a protected getter?

I've heard conflicting things. My teachers told me to always use getters, while other people have told me that using getters at any level reveals bad program design. What's the real answer? I feel like both are illogical extremes.

Also, if getters and setters are bad program design, why is this?

Are there any resources that will teach me more about how to structure my code?

Answer 1

Do you need (or anticipate you will need in the future) to do anything else other than just reading a value? For example: assertions, locking or making the read polymorphic?

• If no, use the field.
• If yes, use the getter.

Whether you use protected or not is completely orthogonal to that.

BTW, managed languages such as C# and Java often require the presence of getters, where "logically" just the ordinary fields would suffice, because their UI design (and other) tools were implemented to use reflection that way. So the practice of excessively using getters seems to have "rubbed off" the C++, despite the lack of reflection or such tools in C++.

Answer 2

protected is closer to public than private. People can create a derived class, access and change the protected members and use their derived instance as an instance of the base class. You can make your decision based on that. If you want a data member to be read-only for the outside world, you need a getter and there is no way around that. A protected getter (and maybe setter) can also work.

Another thing to note is that setters can act as a gateway to your data. They can be used to validate ranges and throw exceptions when needed. Take this into consideration as well.

Also, since you said that it is for use by a certain derived class, you might want to make that class friend. This may or may not be a good idea, you should carefully evaluate pros and cons.

I don't think that getters and setters are generally bad design. I'm sure they can be abused, as almost any idiom or pattern. Generalizing is never a good idea.⁽¹⁾

^{(1) Yeah.}

Answer 3

Your protected and public interface (classes, members, fields) are things that you need to keep stable. Every time you change your protected and public interface, you have the potential to break any code that depends on it.

This might be one line of your own code that you break. It might be hundreds of classes in your own codebase. If you shipped your code somewhat publicly, then you might break thousands of lines of code from hundreds of programmers you've never heard of and will never meet.

Sometimes this break is necessary and good. Sometimes it could have been avoided with a little foresight. Getting into the habit of understanding and considering your reasons for change is the core to good design.

if getters and setters are bad program design, why is this?

Getters and Setters give you only a small amount of encapsulation. You still aren't hiding much from users. They still know there's a field of that type in your code (or at least know you're pretending that that there is), and they depend on it being there. If you changed the implementation of your class in such a way that made that field unnecessary, you couldn't remove the getter/setter unless you were willing to break all dependent code. If you tried to avoid the break, you'd have to make those accessors still work and make logical sense, which might be difficult.

Sometimes exposing a field (or a Getter/Setter) makes sense, even in high level code. If that field is important to access, and would never have a good reason to change name or type (from the view of a programmer using your code), then it might be fine and good and best to expose it in some way.

Sometimes wrapping fields in a Getter/Setter makes sense. If you have Getters/Setters, it can be easier to add logging, bounds checking, thread locks/semaphores, and debugger breakpoints. It is also easier in C++ to define an abstract interface that requires a Getter/Setter to be present than it is to define an interface that requires a field to be present.

Sometimes directly exposing a field, and not using getters/setters makes sense. Sometimes "classes" made entirely of fields makes sense (consider using a struct instead). This is going to be most common in very low level code (such as code that pulls data out of a file), or inside the implementation of another class (such as in the implementation of an algorithm). Often you'll hide these classes inside other classes, so users of your code never see them.

My teachers told me to always use getters, while other people have told me that using getters at any level reveals bad program design. What's the real answer? I feel like both are illogical extremes.

Blanket statements often have truth to them, but truth is seldom binary.

Get in the habit of asking "why?". Get in the habit of judging truth for yourself, and judging situations within their own context. Sometimes what is "always best" is not actually best, or even desirable at all, in a specific situation.