Reputation: 35982
Bjarne Stroustrup once said that he can address most of the tasks with ONLY private or public member variables and he seldom uses protected
member variables in his design. I have heard similar arguments in other places. Here is an example,
class BaseClass
{
...
private:
int m_iAge;
double m_dSalary;
string m_strName;
bool m_bGender;
}
class SubClass : public BaseClass
{
...
}
Given the above class design, how the subclass SubClass
can use the variables defined in BaseClass
?
Question1> Why we should prefer to having private
rather than protected
variables? Is it the reason that the BaseClass
can hide the implementation detail and make it easy for further improvement?
Question2> In order to let the SubClass
access the variable defined in BaseClass
, it seems to me that we have to define public access(get/set). However, getter/setter are evil! So the second choice is to define protected access(get/set). Any better idea?
Thank you
Upvotes: 1
Views: 377
Reputation: 92301
Ask yourself - why would the derived class ever change the value of m_bGender
? Or m_iAge
? Doesn't the base class already handle these values correctly?
See, there is generally no need to have direct access to the internals of the base class. So we make them private, and use the class' public interface.
In some very rare cases, there might also be one or two protected functions, if derived classes need some special interface. But that is unusual. If derived classes have different behaviour, we more often use virtual functions for that.
Upvotes: 1
Reputation: 2590
The only main reason to use private over protected members is if they indeed are not required in child implementations. That's why we have protected members, because there are cases where the child class does need direct access to members of a parent class. I think Stroustrup is referring to a design whereby there is little need to access parent members in the first place, and child classes simply build upon the functionality of their parent rather than modify the functionality of their parent.
However, getter/setter are evil!
Why so? Getters and setters are an important part of OOP from my experience. There are good reasons to make an interface with a class, rather than access its variables directly.
Upvotes: 0
Reputation: 490338
Bjarne's point is that generally the derived class shouldn't access the variables of the base class -- doing so frequently leads to maintenance problems. And no, changing it to use get
/set
(accessor/mutator) functions isn't an improvement.
Upvotes: 2
Reputation: 88418
I think the rationale for this claim is that in many situations, subclassing doesn't often change the behavior of the existing (inherited fields), but rather one adds fields and adds new methods that manipulate the new fields.
If you are looking for a way to manipulate inherited members w/o protected, you can, in the base class, make the derived class a friend. You would have to know it ahead of time, though.
Upvotes: 0