Who needs protected variables?

For years, object-oriented programmers knew that one of the main OOP features is encapsulation: an ability to hide and protect object internals. Private and protected properties were invented to support just this. But who are we hiding from? From stupid developers who will decide to use our smart framework classes.
In some OOP languages only descendent classes can access protected variables from the ancestor. Java relaxed this rule a little bit and allows accessing protected variables from classes located in the same package. Recently, I had to extend a class from a particular third party framework, which had a protected variable defined. My class was not located in the same package as that third party component…

Let’s look at the example: the code below works fine:

public class Father {
    protected int abc = 25;

public class Son extends Father{
   public Son (){
       System.out.println(“abc=” + abc);

public class MyNewClass {
   public static void main(String[] args) {
       Son son = new Son();
       System.out.println(“Son.abc=”+ son.abc);

The MyNewClasss is happily printing

Now move the Father and Son to the package com.thirdparty.framework.
After adding the import com.thirdparty.framework.*; to MyNewClass, the code still does not compile complaining that son.abc is not visible. Of course, because designers of the third party framework wanted to protect their precious abc variable, and they wanted to force me to inherit MyNewClass from their Father or Son.. Did they achieve their goal? Not at all. They just forced me to create a Grandson in my default package with a public getter to the abc property.

import com.thirdparty.framework.Son;
public class Grandson extends Son {
public int getAbc(){
return abc;

And MyNewClass now looks as follows:

public class MyNewClass {
   public static void main(String[] args) {
      Grandson grandson = new Grandson();
      System.out.println(“Grandson.abc=”+ grandson.getAbc());

It’s just annoying that I need to add the GrandSon because designers of the third party framework decided to make the abc protected.

If you want to restrict the access to a property, make it private and give me a public getter, if needed. If you want to let everyone work with a property, make it public.

But who needs this protected access level?

You may also be wondering, what this has to do with Flex? I’ll tell you. ActionScript 3 is also an object-oriented language, and people will create their own components by extending classes that are available in the Flex framework. What if I want to access a variable that exists in a Flex component? If Flex designers made it protected, I’ll have to make my code more complex then needed to overcome this design issue.

4 thoughts on “Who needs protected variables?

  1. Protected is a very important distinction. It’s not so much about the protection of the variable as it is protection of the API. Typically you see this to describe the access levels:

    public : anyone
    protected: pacakge and subclasses
    private: this class (and it’s inner/nested classes)

    However, better to think like this:

    public: public API
    protected: implementation API
    private: private implementation API

    Recast the terms like this, and it becomes quite obvious why the different levels. A protected member is tied to the implementation of a class that subclasses (i.e. classes that share part of it’s implementation) need to be aware of, but which classes that don’t share implementation shouldn’t care about (because it’s not part of their interface). A public member should be totally detached from implementation.

    Of course, it’s easy to botch up your access levels and make something protected that should be public (or the converse), but that’s not an argument for not having the different levels, it’s an argument for ensuring you understand the tools you’re using before you use them.

    NB: each language has specifics that may differ (e.g. Java’s “default” scope). I wasn’t aiming for completeness.

  2. In the switch to the new version of ECMAScript, the private keyword from AS2 received a new meaning in AS3. Now, with private, you can no longer access a variable in subclasses. The protected keyword works like the old private.

    Certainly, if you want to let anyone use a property, you should make it public. There are situations where you want subclasses to access your variables, but not everyone. For example, I often make subcomponents protected so that they can be manipulated by subclasses. Most of the time, a component user doesn’t need to access those subcomponents. If they do, they should probably be subclassing anyway.

  3. Java allows protection even against the scenario you describe, using a concept called “sealed packages”. Else it would be totally insecure to you protected variables cause third party runtime code could mess up with your code (exploit). I’m speaking of running code protection, cause at the disk level, before you run the JVM / classloader, you can open up the JAR files (they are of .zip format) and mess up with the third party classes (unseal the package [at the manifest.mf file], decompile its code etc.). Even if that package is signed you can do various tricks (load the classes via your classloader, store them again to another .zip and mess up with them there, then load that unsigned package or resign it yourself)

  4. BTW, Delphi also doesn’t behave totally purely regarding protected fields, classes defined inside the same unit can treat them as public field. With recent Delphi versions introducting packages concept, maybe they also extend it this protected-fields access to packages scope, but I think not. They must have added a “Protected Friend” concept like in VB.net for that case

Comments are closed.