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

According to Why is Clean Code suggesting avoiding protected variables?, I know there are tons of reasons that I should avoid protected variables. However, there is a reason at the currently highest voted answers : https://softwareengineering.stackexchange.com/a/162657, which I don't understand : why do "protected variables" tend to violate open closed principle? Because I think it is quite opposite, which means protected variables tend to more following open closed principle : When you want to extend the current class, if the new function doesn't require the parent class instance variables to participate, then regardless of if the instance variables are private or protected, you don't need to modify the source code of the base class. However, if the new function requires the parent class instance variables to participate, if the instance variables is private, I need to modify the source code of the base class to change the visibility from "private" "protected" first, or add the getter. In other words, if modifying the base class is not allowed, the "protected" one has more ways to add new functions (modify the base class behaviour) than the "private" one, which should be more following open closed principle. Also, I don't really fully understand what is the meaning of "make assumptions about the protected member", I guess it is about the preconditions or invariants of the protected member. But even if preconditions or invariants are changed, I think it is not a kind of "extension", but "modification", 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. And if the reason is "it may tend to add instance variables in order to add a new feature", I still disagree that it tends to violate open closed principle. While it may be an actual problem, I think it doesn't mean it is violating "open closed principle" : if there are some protected instance variables that is not necessary afterwards, deleting them from the base class should be a kind of "modification", not "extension". While I agree there are other reasons to avoid protected variables, "tend to violate open closed principle" seems not one of them, and I think it is quite opposite : it tends to be more following open closed principle because there are more chance to add new features but not required to modify the base class (change the visibility from private to protected or add getter). So my question is, why would the answer suggest "protected variables" tend to violate open closed principle? Or I misunderstood the answer?

Mar 31, 2025 - 09:19

According to Why is Clean Code suggesting avoiding protected variables?, I know there are tons of reasons that I should avoid protected variables.

However, there is a reason at the currently highest voted answers : https://softwareengineering.stackexchange.com/a/162657, which I don't understand : why do "protected variables" tend to violate open closed principle?

Because I think it is quite opposite, which means protected variables tend to more following open closed principle : When you want to extend the current class, if the new function doesn't require the parent class instance variables to participate, then regardless of if the instance variables are private or protected, you don't need to modify the source code of the base class. However, if the new function requires the parent class instance variables to participate, if the instance variables is private, I need to modify the source code of the base class to change the visibility from "private" "protected" first, or add the getter. In other words, if modifying the base class is not allowed, the "protected" one has more ways to add new functions (modify the base class behaviour) than the "private" one, which should be more following open closed principle.

Also, I don't really fully understand what is the meaning of "make assumptions about the protected member", I guess it is about the preconditions or invariants of the protected member. But even if preconditions or invariants are changed, I think it is not a kind of "extension", but "modification", 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.

And if the reason is "it may tend to add instance variables in order to add a new feature", I still disagree that it tends to violate open closed principle. While it may be an actual problem, I think it doesn't mean it is violating "open closed principle" : if there are some protected instance variables that is not necessary afterwards, deleting them from the base class should be a kind of "modification", not "extension".

While I agree there are other reasons to avoid protected variables, "tend to violate open closed principle" seems not one of them, and I think it is quite opposite : it tends to be more following open closed principle because there are more chance to add new features but not required to modify the base class (change the visibility from private to protected or add getter). So my question is, why would the answer suggest "protected variables" tend to violate open closed principle? Or I misunderstood the answer?