Do You Need to Worry About Nasty Protected Variables?

Written by Kristijan Kralj in Software Engineering

The protected variable specifies that the parent class and all other classes inherited from that class can access and modify that variable in the same or some other assembly.

In this way, a protected variable allows easy modifications and dynamic redefinitions according to the needs of a program. However, many professionals argue that you should avoid the protected modifier at all costs.

As a general rule, you should avoid using protected variables unless necessary. This is because protected variables are accessible by the derived classes of the parent class, which breaks down the encapsulation of code.

This post will explain how protected variables function in your code and why avoiding them might keep your code clean.

Should you avoid protected variables?

The keyword “protected” is an access modifier that defines the extent to which a program can manipulate the protected member, class, or datatype. Unlike the most common public class members, a protected variable allows comparatively restricted access to the rest of the program in terms of modifying and reading the variable.

As stated in the article’s beginning, protected variables might break the encapsulation rule.

Encapsulation means that closely related data and methods should be grouped into a single unit. Without it, invariants become available to be accessed by the subclasses. That increases the chances of disturbing the functioning of your code. But also, it can be a security threat due to the implementations being in front of every user.

Since the protected modifier gives access to the variables in any inheritance class, the code becomes scattered over the entire program. Furthermore, these sub-classes can now modify, redefine and access these variables to make changes to the program functioning. That can make the code difficult to debug and change.

Take this code snippet, for example:

class Rectangle
{
    protected int height = 123;
    protected int width = 300;


    public int GetRectangleHeight()
    {

        return height;
    }

    public int GetRectangleWidth()
    {

        return width;
    }
}

class SubRectangle : Rectangle
{
    internal static void Main()
    {
        var b = new SubRectangle();

        b.height = 10;

        Console.WriteLine("Height: {0}", b.GetRectangleHeight());
        Console.WriteLine("Width: {0}", b.GetRectangleWidth());
    }
}

In this case, the protected variables defined in the base class were given a different value during inheritance. The subclass sets the height to 10. The call to the GetRectangleHeight method returns the new value instead of 123.

If the purpose was to keep the original height and width constraints intact, this would create severe problems if another person working on the code changed the values or functioning.

Why does the Clean Code book suggest avoiding protected variables?

Clean Code is a guide written to teach programmers how to keep their code efficient, readable, and impactful. Out of the many tips in this guide, it also suggests avoiding protected variables.

In the section that talks about Vertical Distance, in the Chapter “Formatting,” Clean Code suggests that you should not use protected variables often as they increase the vertical distance between the code. According to the book, closely related code snippets should be kept as close together as possible, which is another way to define the encapsulation concept.

Here are a few implicit reasons why Clean Book might be suggesting to avoid protected variables:

  • Difficulty in making changes – You will need to change the base class at some point. However, you will need to go through multiple derived classes and detect all the changes to ensure your modifications are working correctly due to protected variables. Thus, broken encapsulation leads to difficulty in making even the most minimal changes to your code.
  • Impossible to maintain invariants – With protected variables, maintaining invariants is impossible. Since the variables are accessible to multiple derived classes and from multiple files, there is a probability that a chance may occur somewhere in between, affecting the variable’s original value. Furthermore, if multiple programmers are working on a project, protected variables also give them the liberty to mess up your logic.
  • YAGNI issues – YAGNI issues are common when you incorporate something in your code that you will not need. So, unless there is some derived class that will use the variables, it’s better to make them private or public.

Due to these reasons, Uncle Bob argues that you should avoid protected variables, if possible.

Generally, when a class is only meant to carry data, you should make it public. However, if the class will have logic along with data, both should be tightly coupled by making the members private.

If they are made protected, the base class will have infiltration from derived classes, spreading the logic throughout the program.

Conclusion

Protected variables do more harm than good. They break encapsulation, spread the logic in different classes and files, and makes debugging and modification a challenge.

Therefore, if you want to write readable and editable code, a good practice is not to use protected variables.

Recent Posts