3

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?

ocomfd
  • 5,652
  • 8
  • 29
  • 37
  • 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 Jun 08 '17 at 03: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. – Tanner Swett Jun 08 '17 at 04: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. – candied_orange Jun 08 '17 at 04: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. – Roman Reiner Jun 08 '17 at 05:07
  • 1
    @Euphoric Just because something has uses doesn't mean it's worth the cost. – Derek Elkins left SE Jun 08 '17 at 07:22
  • Inheritance is sometimes used badly as a conveniance by people with little experience or that don't really care (and sometimes honest mistakes). If you remove that to them, they will find something else and will use them as bad as inheritance. – Walfrat Jun 08 '17 at 14:13

3 Answers3

4

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.

Martin Maat
  • 18,218
  • 3
  • 30
  • 57
2

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.

JacquesB
  • 57,310
  • 21
  • 127
  • 176
2

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.

David Arno
  • 38,972
  • 9
  • 88
  • 121
  • 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 Dec 03 '19 at 22:43