A co-worker of mine is taking an Introduction to Object Oriented Programming class and was asked a discussion question by his professor:
Why are many developers opposed to using the “protected” modifer on/within classes?
When the question was brought up at lunch, my co-workers and I couldn’t think of reasons why someone might be opposed to using the protected modifier on a class. Setting the premise of the question aside (which assumes that many developers are in fact opposed to the protected modifier; are they?), we tried to figure out why.
Personally, the only times that I’ve used the protected access modifier on a class is when I’ve written code that I might want to supplement in a test environment. For example, I might write a base class with no debugging information and then create a new class for testing, inheriting from the base class and overwriting its methods to add in debug output code before/after the base method calls. I suppose I could just as easily use a design that involves interfaces and dependency injection to accomplish the same goal, but my only experience with protected has been for testing purposes. In this case, the only reason to avoid protected is because you can accomplish the same thing in better ways.
Why might developers be opposed to using the protected modifier in their OOP design?
NOTE: Because the professor is asking a general OOP question not specific to any one language, I’m not sure if answers might be weighted differently because of different implementations of protected in C#, Java, etc..
Developers don’t complain about protections until they prevent the developer from getting to something they want to use. For developers that are creating child classes, protected is no big deal because they’ll have access to the goods from within their child classes.
For developers that are using a given class (not extending it), protected blocks access to potentially juicy internal implementation details. This is what they will gripe about.
It can be said that some framework designers err too much on the side of privacy – deny access to everything and only allow access to specific documented, supported features. This can be frustrating when you know there’s good stuff on the inside that you could use to solve your immediate problem, but consider the flip side: if your framework were instead designed by someone who gave free access to everything, all the internal details of the implementation, you will very likely encounter one of two things when the framework is updated at some point in the future:
Even though it’s frustrating to see things you can’t access, it’s better for code longevity and lower revision costs to operate in a restrictive (deny all, permit by exception) mode than in a permissive mode.
I have worked on (nay, written) frameworks in which developers using the framework complained about it not being permissive enough with internal details. These folks complained even as bugs were fixed, features were added and the implementation was rewritten across various platform migrations, but the public, supported interface, the contract of the code remained stable and their code remained largely unaffected.
So, in a nutshell, developers will complain about protected (and private) access modifiers simply because it gets in the way of what the developer feels would be the simplest and fastest way to implement a solution, ignoring the future cost of relying on such implementation details.
Encapsulation is a good thing, even when it blocks the shortest path to solution. ;>