# What's your take on protected variables?

This topic is 1894 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

No. As I see it, the Circle class will include all three: width, height and diameter. The width and height still serves the same purpose for Circle class as it did for Rectangle class. Now, the diameter variable (or maybe radius), will be used to calculate the area of the circle.

So now you (the programmer) are having justify the inclusion of width and height in your code, and need to band-aid the class to keep width and height in sync with diameter. Why? So you don't have to "bother" adding width and height to the classes that do need it? At the expense of muddying the classes that don't need it?
There's a more serious, but more subtle issue with re-using the Shape's width, height, x, and y. As I already mentioned, you'd actually be re-purposing either width or height for a different purpose. But how many people here realize you'd also be re-purposing x and y for a different purpose as well?[/quote]

I don't agree with this. The width and height variables are raw data. Data should be used for whatever it needs to be used.[/quote]
Well, you might as well repurpose every variable in your code, type-casting ints to bools to chars as you need them, and only have one variable in each function called "data". For the sake of code clarity, each purpose should have it's own distinct variable with a good variable name that describes the purpose. Each variable type should describe the generic use of the data.

Of course, the 'x' variable could be named better, let's say 'x_coordinate', or even better, as you say, it could be a point.[/quote]
x_coordinate does not help any more. 'x' is assumed to be a coordinate. The reason I was suggesting it be put in a class/struct, is to force the user of the class to give it a real name, that actually describes its purpose. "topLeftCorner" vs "center" is a completely different purpose, that just happens to share the same generic usage (describing a point in space).

But my argument is that EVERY child of the Shape class will need a x variable and a y variable, or a point, etc.
It doesn't matter where the point will be located in the shape, the object stills need it.[/quote]
But it actually does matter, for code legibility and for the least amount of surprise.

You are saying, every subclass of Shape has x and y, but they can mean different things in each subclass... which means if you use polymorphism, your own code cannot assume that Shape.x means any specific location. That is bad! You're also saying, the end user of the subclass has to look up (for each individual subclass) what x and y means in context to that specific subclass... instead of making the code self-documenting by letting the variable name explain its own purpose.

The only thing each x has in common in each subclass is that it represents a location on a grid. You might as well have each Shape have member variables called "int number", because, hey, each Shape subclass probably might use a number to represent something.

The Circle class example is the 'whale' of the mammals class.[/quote]

And I can't conceive how the child can't have access to the parents data when he is INHERING from that same class. If you permit to me make another example:

[source lang="cpp"]class Dog{
private:
Fangs fangs;
//many other variables
};
class GermanShepherd : public Dog{}[/source]

So you are telling me that class GermanShepherd can't have access to Dog class's private variables?[/quote]
I'm more curious why you are telling me that the user of Dog can't have public access to the dog's Fang.

Or are you going to argue that some dogs don't howl, so they don't fit together in a class. Should I compose GermanShepherd class from Dog class?[/quote]
Unless a GermanShepherd has some kind of implementation detail that differs from regular dogs, it should actually be:
Dog myGermanShepherd(...initialization data for the minor differences...);

But if the GermanShepherd *does* have implementation details that differ from regular dogs, a GermanShepherd is-a Dog, so inheritance is correct in this situation. The question is, does a GermanShepherd really need to know the implementation details of its Dog base to function? Every class should mostly be a black box, lest your subclasses become dependent upon implementation details that may later change. Dependency on interface details are fine (and unavoidable), but not implementation details.
You are arguing against inheritance, not against protected variables![/quote]
I am arguing for proper use of inheritance and composition, which gets rid of the need for protected variables.
Good design eliminates every need for protected variables and functions (at least that I can think of), with only the possible exception of virtual functions... and I'm not even sure if that is truly needed.

Protected variables are fine, if we need them - since good design eliminates the need, why have them if they only enable bad design?

As a beginner programmer, I went from "all members public", to "all members private" (I've also done, "all base class members protected"). Now, I recognize that you can't make hard and fast rules that say "always do X" or "always do Y", so my member variables are more and more becoming public again, unless they are an implementation detail, or unless the implementation needs to do something when setting or getting them. A subclass can easily access the public elements, and use the getters to access the non-public but interface-visible variables.
I don't think a subclass should be able to access anything that a standalone function can't.

I obviously can'y say, "Every use ever of protected variables come from bad design", but I can say, "Every single of my uses of protected variables were a result of my bad design" (or else me doing it "just because"). They probably have some kind of use in butchering the C++ language in weird ways to add new language features, like Boost does.

Boost 1.50 shows 133 uses of of 'protected' in 10,335 classes*, less than 1.5% - so I guess Boost has found some uses for them - they may be misusing them, however, but I'd bet the average Boost developer is a better programmer than I (but again, Boost abuses C++ features to extend the language - so it's not regular code).

*[size=2]869,059 lines of code, not including whitespace. Edited by Servant of the Lord

##### Share on other sites
I think its useful when your intending on creating a derived class that is derived from multiple parent classes.

##### Share on other sites

I think its useful when your intending on creating a derived class that is derived from multiple parent classes.

Can you elaborate on that?

Does that read as: it's useful to have protected members in parent classes when using multiple inheritance?

IMO if you're in the unfortunate situation that you must use multiple inheritance, don't add more confusion to the mess with protected members.