Is it good practice to make member variables protected?

Question

Asking this question because I feel that member variables of my base will be needed later in derived classes. Is there a drawback of making them protected?

EDIT: Edited to better show my intention.

EDIT: @sbi : Is this also wrong?

This class will be used for error recording and retrieving in other classes. Is it better to derive from it or use an object of it - I don't know. But I think the getter and setter methods are what this class is all about.

class ErrorLogger
{
   public:
      //Making this function virtual is optional
      virtual void SetError(const char*, ...);
      const char* GetError() const;
   protected:
      char* z_ErrorBuf;
};

Answer 1

I am curious of what other people will answer to that.

As well as for the accessors paradigm, you may declare them private and use protected Getter and Setter methods. If your base class implementation changes, you only have those getter and setter to modify.

Answer 2

If you think child classes will need access to those variables later then yes, make them protected.

There is no drawback, as long as the aforementioned condition is met.

If you want to take the extra step and protect your variables from outside access, you could always create private member variables and then use protected methods to access/modify those private variables.

Answer 3

Inheriting is just another way of using a class. It is more coupled and by making your member variables protected, you couple even more, so you shouldn't change them without knowing the impact on every inherited class. If it is your base-class and your inherited classes, there's probably not going to be any harm, but you do lose control of how members should be accessed (locking, logging, read/write, persistency,...).

Answer 4

Your overall class design will show you if you will end up with protected members or not. Whether you make them private, protected or public, that isn't something thats chiseled in the stone, so feel free to create your class tree without much thinking about that. If at first you don't know if the member will be used by derived class, and in what way, you'll surely find out when coding.

Most important thing to decide is what is public vs /private, because that's the way you present your class to the outside world.

Answer 5

Encapsulation is one of the main features of OO. Encapsulating your data in classes means that users of the class can not break the class' data's invariants, because the class' state can only be manipulated through its member functions.

If you allow derived classes access to their base class' data, then derived classes need to take care to not to invalidate the base class' data's invariants. That throws encapsulation out of the window and is just wrong. (So do getters and setters, BTW.)

I find myself using protected less and less over the years, even for member functions. If a class fully implements a simple concept, then all of its state should be manipulatable through its public interface. If derived classes need "back doors" to sneak in, then I usually question my design. (Which isn't to say I never use protected. I just find I need it less and less.)

Answer 6

Protected data has all the drawbacks of public data, so you might as well make them public.

Answer 7

If you make them private and later decide that they need to be accessible to derived classes, you can change them to be protected without affecting any code dependent on that class. You also have the option of adding protected accessors.

If you make them protected and later decided that should be private, changing them could break existing code that relies on them being available.

My personal rule of thumb is to make everything private and promote them up the visibility chain as necessary.

Answer 8

As long as you didn't intentionally design the class to be inherited from then there's no reliable way to guess what methods should be virtual and what members should be protected. The only thing you can be sure about is that you'll very likely guess wrong.

Don't mess around with this, use the sealed keyword and make the members private. You can always refactor later, you will have to anyway.

Answer 9

Provide a protected getter and maybe setter to the private internal variable, it's a little more code, but it's much cleaner.

Answer 10

You don't make members public for a reason. Even if those members can be freely set or got. You provide dummy public setters and getters. For EXACTLY THE SAME REASON you should NOT make members protected. Instead, you should provide protected setters and getters. The symmetry is very strong.

Answer 11

Making something 'public' creates a contract that will be binding upon all inherited classes. Making something 'protected' creates a contract with directly-inherited classes, but does not compel the classes to make such a contract available to any of their descendants.

If one expects that the source code for a base class will be available to anyone who is inheriting from it, and expects that the base class will never change (typically this means that the reason for using the base class is to allow public members and properties of the base-class to be used interchangeably with derived classes, rather than to reduce the amount of code needed for the derived classes) and if all public methods are virtual or tie directly into virtual methods, there's not much disadvantage to using protected fields rather than protected virtual getters/setters. If a descendant class needs to change the way the fields are used, it can simply override all the methods that use them.

If one expects that derived classes may be created in situations where the classes above them in the hierarchy are not completely known or are not immutable, then it may be more appropriate to have protected getters/setters, but that responsibility could be left with whoever creates the 'opaque' layers in the hierarchy.

Example: a collection might maintain a field called 'count'. A base version of the collection may store things in a way that makes it easy to maintain a field that always holds the number of items, but a derived version might store things in a way that makes it difficult. By having a field called "count", the base class promises its direct descendants that it will maintain the number of items in that field. A derived class might store things differently, such that a "count" field wasn't meaningful. Such a class could shadow the count field with a read-only property; its descendants would know that they had to read a property, while descendants of the original class would know that they could read a field.

The most important point is that protected things in a class only create a contract with direct descendants, and those descendants can decide whether or not to make a similar contract available to sub-descendants.

Addendum: the only thing gained by adding protected virtual getters and setters will be the ability for derived classes to change how the base class code accesses the fields/properties. Sometimes this will be necessary, but more often it will create problems. For example, if a collection may frequently have recently-added items deleted, a derived class may wrap things so that the last few items added are kept in a small "bonus" collection and transferred to the main collection after enough additional items are added. Code for the main collection will be expecting its own "count" field to indicate how many items are in the main collection. If a descendant class overrides the "count" property to include its own items, the main code will break. The descendant class should instead shadow the count field so its descendants will see a count that includes the bonus items, but the base class will still see the count which only includes its own items.

Answer 12

Personnally, I usually try to restrict my use of protected to virtual things.

I consider any other use of protected as conceptually equivalent to public. In the sense that if you write a non virtual protected method, write it as if it was public. Same for a field. If the field would break something if it was public, it will also break something if it's protected.

It doesn't mean it's bad to have a protected field or non virtual method, it just means you have to be careful and deliberate with their use, and know that someone, somewhere, can use those things and potentially break your class simply by deriving it.