I've seen some posts which has strong reason to avoid using protected:

Why have private fields, isn't protected enough?

Why is Clean Code suggesting avoiding protected variables?

And there are some other posts suggested we don't need inheritance actually:

Why should I prefer composition over inheritance?

And some other posts suggested that inheritance can have alternatives:

Is this a misuse of "composition over inheritance"?

Should I force "composition over inheritance" rule to class members?

So I have a rather 'modern' idea : If 'protected' field is so harmful, should OOP languages eliminate keyword 'protected' in order to force programmers to write clean and high quality codes? If the answer is 'NO!' , what is the reason to allow 'protected' fields? Eg: when do we need 'protected' actually?

  • 3
    Just because something is "bad" doesn't mean it hasn't it's uses. Inheritance still has it's uses, even if you heavily prefer composition.
    – Euphoric
    Commented Jun 8, 2017 at 3:46
  • 1
    I don't see any arguments here that protected methods are harmful or not useful. Methods are not fields. If there are no arguments for eliminating protected methods, then we certainly should not eliminate them. Commented Jun 8, 2017 at 4:08
  • 1
    @TannerSwett For anyone creating a new language I'd like to see the burden of proof on the other foot. When designing Go they resisted adding anything until a good argument had been made for its need. I'd rather not work in a language cluttered with every kind of idea. Commented Jun 8, 2017 at 4:24
  • 2
    Did you read the answers to the linked questions too? Most of the answers seem to disagree with the premise of those questions. Commented Jun 8, 2017 at 5:07
  • 1
    @Euphoric Just because something has uses doesn't mean it's worth the cost. Commented Jun 8, 2017 at 7:22

3 Answers 3


It is all about avoiding noise and keeping your scope tight. The only way for descendants to access parent members would be to make those members publicly accessible, which would expose those members to clients (users of the class) as well. This could be not useful, puzzling and dangerous. It would most certainly not be clean. Littering would be the word, you would be littering internal functionality of classes all over your namespaces. It would be so messy.

  • Unless we had a language with interface segregation built in well. Commented Jun 8, 2017 at 6:20
  • Note that you can eventually have protected read only fields by making them private and give only a protected getter on it.
    – Walfrat
    Commented Jun 8, 2017 at 14:10

Those advice is only against protected fields. You would still need protected for methods. It is related to the common advice against public fields. In effect, they are arguing fields should always be private and only exposed through getters/setters.

It is sensible advice in general, but sometimes a public or protected field is the simplest and most straightforward approach, and adding getters/setters would be needless code bloat, so I would not like it enforced by the compiler. It all depends on context.


Inheritance suffers from numerous problems, such as the fragile base class problem, creating tight, bi-directional coupling and weakening encapsulation. Further it can make testing harder than it needs to be. (See Inheritance: just stop using it already! for details of all of the above [disclaimer: written by me]).

There are no use-cases that I have been able to find where inheritance works better than using a combination of designing to interfaces and using composition.

There therefore is a good case for having modern languages not support inheritance at all. However, if they do support it, then protected remains needed. Without it, folk would still use inheritance, but they'd be forced to weaken their encapsulation even further by making those members that sub classes override, public. And just removing inheritance from existing languages would break existing code, so that's a non-starter too, unfortunately.

  • How would you efficiently handle situations involving extensible objects whose job is to be part of exactly one "forest" of inter-connected objects (e.g. components in a UI or simulation)? I would think that having components derive from a base class that was maintained by the same entity as the forest class would allow more flexibility in the forest design than would having components be interfaces. One could use a sealed component class whose clients had to pass callbacks to configure its behaviors, but that would seem rather clunky.
    – supercat
    Commented Dec 3, 2019 at 22:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.