Why do "protected variables" tend to violate open closed principle?

Original answerer here. Thanks for reading, and thank you for following up with this question.

First, the Open Closed Principle.

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

I know that wikipedia, and some of my fellow answers focus on source code, but I do not. The SOLID principles, like most engineering guidelines, are there to help people make better software with fewer bugs. They're years and years of engineering experience distilled into a witty quip so that you'll remember them. Following rules for the rules' sake is a waste of time.

Changing source code isn't what you should be focusing on. Almost all of programming is changing source code.

What the OCP tries to prevent is a modification of behavior, while allowing you to extend the behavior.

So your point:

modifying the base class because of preconditions or invariants are changed instead of because of adding new features seems doesn't violate open closed principle.

It absolutely does.

Think of it this way: You are responsible for a base class. It's used by thousands and thousands of programs around the world. Some inherit from the base class. Some compose it with other classes. Some merely consume it. It works great.

Now you change the invariants and post-conditions of that base class.

How the hell are you going to verify that it still works great for all of your users?

That's the sort of thing that the OCP exists to deal with. If all you do is extend the base class, while maintaining invariants and postconditions then you are safe.

---

Protected variables are more dangerous here because of scope.

If the variables were private, you could be certain (or reasonably certain in some languages) what their invariants were. They could only be modified in the base class and every consumer depended on that exact behavior. But for protected variables, they can be written by any subclass, anywhere. Better than global variables and better than public variables, but that same sort of danger. Code you don't know about is doing stuff to variables you're trying to use.

It's practically inviting bugs into the system.

---

The gotcha here of course is that many of the invariants and post-conditions of protected variables are implicit. There's no type constraint on them, or any linter enforcing the behaviors.

Yes, people can use protected variables without breaking the implied contracts, but my years and years of engineering experience (including the twelve and a half years since my original answer) is that they substantially increase the risk of breaking things.

The original OCP paper addresses this directly. Under the section "Make all Member Variables Private", we find:

This is one of the most commonly held of all the conventions of OOD. Member variables of classes should be known only to the methods of the class that defines them. Member variables should never be known to any other class, including derived classes. Thus they should be declared private, rather than public or protected.

That's seems like an 'open-and-closed' case as to whether protected members violate the principle, at least according to 'Uncle Bob'. As to why, he explains:

When the member variables of a class change, every function that depends upon those variables must be changed. Thus, no function that depends upon a variable can be closed with respect to that variable.

... we do expect that any other class, including sub-classes are closed against changes to those variables. We have a name for this expectation, we call it: encapsulation.

You should probably read the original for the rest of his argument, but I'll add one more excerpt from the end of the section which shows that he explains that it's not strictly the case that protected variables violate the principle:

Thus, in those rare cases where the open-closed principle is not violated, the proscription of public and protected variables depends more upon style than on substance.

TL;DR The answer you linked makes a few too many assumption, in my opinion, about a cherrypicked scenario where something is already going wrong. Your interpretation, based on the question you posted here, is mainly focused on scenarios that are polar opposites of the scenarios that the original answer focused on, which is why you're not seeing a lot of agreement between their stance and yours.

Realistically, it's contextual. It depends on what kind of scenario you find yourself in. But for the purpose of defining a generalized good practice guideline (as opposed to a specific targeted feedback to a specific group of devs), I align myself with your stance more than that of the previous answer's.

Part of this is a clash of definitions.

If I see a protected variable, my inference is that the designer of the base class exposed it there for me to use (if I need to). But the answer's first bullet point:

1. They tend to lead to YAGNI issues. Unless you have a descendant class that actually does stuff with the protected member, make it private.

... interprets it differently. They're arguing a scenario where exposing the variable (by making it protected) was done without consideration that a derived class would make use of it.

The issue here is one of context. If the base class has not been designed to account for how any derived classes intend to alter it, yeah then the base class should not be exposing variables which allow derived classes to alter how it works.
At the same time, if a base class has already considered (as part of its design) how to allow derived classes to alter it, then it invariably needs to expose this access via protected members (fields/properties/method as is appropriate).

Which brings us to the second bullet point in the answer:

2. They tend to lead to LSP issues. Protected variables generally have some intrinsic invariance associated with them (or else they'd be public). Inheritors then need to maintain those properties, which people can screw up or willfully violate.

... and again, the interpretation made by the answerer is that things were made protected before/without considering if and how they should be used by deriving classes; which in my opinion makes little sense.

However, that's not to say that "don't expose what you're not ready to handle yet" doesn't make sense. I've worked in teams where the vast majority were inexperienced juniors and they needed to be told this information.

But as far as mid-level (or above) developers are concerned, this advice seems trivial, and the second bullet point seems to operate from an assumption that the preceding developer exposed things that they were not able to have altered by outside sources, which amounts to pointing out a rookie mistake, not providing an advanced development guideline for non-rookies.

Third bullet point:

3. They tend to violate OCP. If the base class makes too many assumptions about the protected member, or the inheritor is too flexible with the behavior of the class, it can lead to the base class' behavior being modified by that extension.

... is in my opinion irrelevant. I don't mean that the opinion is wrong, I mean that it's just on another topic entirely. Whether or not a member should be made protected is a completely different question from judging how a base class could potentially have implemented any logic surrounding that member in a less-than-ideal way.

Not making members protected is not going to stop an OCP-violation-creating developer from creating OCP violations in their code. They're just two completely unrelated considerations.

Fourth bullet point:

4. They tend to lead to inheritance for extension rather than composition. This tends to lead to tighter coupling, more violations of SRP, more difficult testing, and a slew of other things that fall within the 'favor composition over inheritance' discussion.

... is not very wrong in the sense that relying on protected access modifier inherently means relying on inheritance, and there is a general shift towards composition over inheritance.

However, we again strike on that same kind of different interpretation. Yes, it's correct to say that a developer should consider composition over inheritance. No, that does not mean that you should never use inheritance. And no, therefore it also does not mean that there is never a scenario to use the protected access modifier.

On the premise that inheritance is the right call in a scenario, there is nothing wrong with then using protected members where appropriate. The fourth bullet point's assumption that protected access modifiers are a gateway drug to overuse of inheritance is again, in my opinion, nonsensical.

But it would be unfair for me to omit the closing sentiment of that answer:

But as you see, all of these are 'tend to'. Sometimes a protected member is the most elegant solution. And protected functions tend to have fewer of these issues. But there are a number of things that cause them to be treated with care. With anything that requires that sort of care, people will make mistakes and in the programming world that means bugs and design problems.

... because they are right here, things are contextual and there are cases where it is the right approach, and cases where it is the wrong approach.

The part of the answer I disagree with is the interpretation that the use of the protected access modifier was executed before considering that it was a good call to give derived classes access to this member and considering if inheritance was even right in the first place.

In my opinion, that is a nonsensical interpretation in most cases. This may be good advice for specific developers who are making that specific mistake of exposing things before evaluating their design; but I don't think it's a productive basis for a broader good practice guideline, which is what that answer is intending to establish.

I agree to JaquesB's answer that introducing protected member variables does not literally violate the OCP - protected members do not make a class technically less closed against modification or less extensible.

What I don't think is that the linked answer is wrong in full about the OCP. Protected member variables (tend to) make it harder to follow one of the goals of the OCP - which is IMHO not just to make a class or component extensible, but also to make it easy that users of a class extend it correctly. Reusage of a component by extension should not be errorprone, and a component which is designed for reusage should not make it easy for a user to introduce subtile errors without noticing. That is specifically an issue when the component is a compiled black box, where one cannot see in detail how a protected member variable is used inside, or which invariants the component designer had in mind.

In this sense, a class which contains protected members tends to be "too open" for extensions, more open than it should be to prevent errors.

The linked answer is just mistaken about the Open-Closed Principle. The answer talks about causing changes in the behavior of a base class, but the Open-Closed Principle is about avoiding changes in the source code of the base class.

Altering behavior through extensions is the entire point of the Open-Closed principle.

The liked answer list the principles YAGNY, OCP etc. as it is a checklist and you want to conform to them all. This is an (unfortunately common) mistake. The principles should be used tools, not dogmas. In reality OCP and YAGNI are largely contradictory principles, and you have to select which principle is appropriate for a project.

OCP is appropriate when the code is published in the form of a library and consumed and extended by third parties in code-bases you do not control. Any change to a base class will have a high risk of breaking some existing code. You have to think about the ways consumers might want to extend the components and carefully design the base classes and interfaces for extensibility.

YAGNI is appropriate when you have full control over the source code and you have automated tests which detect if a change introduce bugs. You don't need to complicate the code by designing for potential future extensions which might not happen. Instead you extend or alter the code when you need it.

Unfortunately, much advice does not distinguish between these very different scenarios.

A downside to protected (and public) variables is you can't change the implementation later. For example adding validation or change the underlying representation in the base class would be a breaking change for the client. Therefore it is recommended to use getter/setter instead of just exposing a private variable. In theory this criticism should not apply if you follow the OCP, since you are not supposed to modify the base class anyway. But the original version of the OCP acknowledged that it is OK to change base classes to fix outright bugs. So you should still follow good practices of encapsulation.

I guess the argument is that by changing the state of a protected variable you modify the functionality of the base class.

eg

public class Base { protected bool isOpen; public Task DoThing1() { isOpen = getConnectionState(); .. } public Task DoThing2() { if(isOpen) {... //more optional stuff } 

Now if I inherit and have some new method

public class Child : Base { public Task DoSomethingElse() { isOpen = false } 

I've modified the behaviour of the base in the same way as if I had been able to change a private variable. Calling :

x.DoThing1() x.DoThing2() 

Is not the same as :

x.DoThing1() x.DoSomethingElse() x.DoThing2() 

The change is a modification rather than an extension because we have no control over the side effect. A new version of Base might break the combined functionality. If it wants to be sure not to, it has to treat protected like public.

So the question is really, "What's so special about an inherited class that it should be allowed to change stuff that other classes can't?"

After reading through the comments to my and other answers I will take another crack at it.

There seem to be two key points that are being made:

#1 - All mutable member variables should be private - simply because any protected or public members could be mutated at any point / hence you don't have control over when such mutations occur / as a result you can't include that variable in the invariants.

#2 - The other argument is that methods shouldn't be marked protected either, the logic being that a subclass shouldn't be granted any special access - it should use the same public methods that anyone else can use.

I disagree with the second point if the parent class is Abstract - I can see the need to force an implementation of a protected method.

More generally I can see the need for protected methods if there is a possibility that a child class may override the functionality / override an empty method to receive an event.

However I am tempted to agree that for methods that are not overridden its difficult to come up with a use case where only a subclass would need access to call a method (such methods could/should be public in such cases).