Access Modifiers – Why Have Private Fields When Protected Is Enough?

access-modifiersencapsulationobject-oriented

Is the visibility private of class fields/properties/attributes useful? In OOP, sooner or later, you are going to make a subclass of a class and in that case, it is good to understand and be able to modify the implementation completely.

One of the first things I do when I subclass a class is to change a bunch of private methods to protected. However, hiding details from the outer world is important – so we need protected too and not just public.

My question is: Do you know about an important use case where private instead of protected is a good tool, or would two options "protected & public" be enough for OOP languages?

Best Answer

Because as you say, protected still leaves you with the ability to "modify the implementation completely". It doesn't genuinely protect anything inside the class.

Why do we care about "genuinely protecting" the stuff inside the class? Because otherwise it would be impossible to change implementation details without breaking client code. Put another way, people who write subclasses are also "the outer world" for the person who wrote the original base class.

In practice, protected members are essentially a class' "public API for subclasses" and need to remain stable and backwards compatible just as much as public members do. If we did not have the ability to create true private members, then nothing in an implementation would ever be safe to change, because you wouldn't be able to rule out the possibility that (non-malicious) client code has somehow managed to depend on it.

Incidentally, while "In OOP, sooner or later, you are going to make a subclass of a class" is technically true, your argument seems to be making the much stronger assumption that "sooner or later, you are going to make a subclass of every class" which is almost certainly not the case.

Related Solutions

Object-Oriented Design – When Too Much Encapsulation is Reached

The fact that your code is not being written as a public API is not really the point--the maintainability you mention is.

Yes, application development is a cost center, and the customer does not want to pay for unnecessary work. However, a badly designed or implemented application is going to cost the customer a lot more money when they decide that it needs another feature, or (as will certainly happen) the business rules change. Good OO principles are there because they help make it safer to modify and append the code base.

So, the customer may not directly care what your code looks like, but the next guy who has to modify it certainly will. If the encapsulation (as you're defining it) is not there, it's going to take him a lot longer and be much riskier for him to do what he needs to do to serve the customer's needs.

Object-Oriented Design – Use of Association, Aggregation, and Composition

The distinction between association, aggregation and composition as you describe it is a legacy going back to the old times of manual memory management. For example in C++ the memory used by objects has to be manually released and it is thus paramount to carefully design the lifecycle of composed objects. While the distinction between aggregation and composition is still being taught by many text books, it is essentially irrelevant when programming in environments with automatic memory management. If you have garbage collection all of them are just composition, period.

Encapsulation on the other hand is a much more general principle than what you describe. It is foremost the idea of bundling data and the functions that operate on this data in one module. One way to implement this is by keeping the state of the module private and expose changes to that state through public services. So client cannot access the state on their own but have to tell the module their intend by sending messages. So encapsulation is not limited to objects but applies to services as well. Actually, one way of looking at objects is to look at them as services.

Here's an example of encapsulation

public class Counter {
    private int n = 0;
    public int inc() { return n++; }
}

or the same using lambda functions

var counter = (function() {
    var n = 0;
    var inc = function() { return n++; }
    return inc;
})();

In both cases the data, that is the variable n, is bundled together with the function inc that operates on it. And there is no way any other function could ever access n, thus we have an encapsulated module that provides counting as a service.

NB: exposing all of an object's inner state through accessors is actually a violation of encapsulation. Alas, it is such a common violation that many will confuse it with good object-oriented design.

Best Answer

Related Solutions

Object-Oriented Design – When Too Much Encapsulation is Reached

Object-Oriented Design – Use of Association, Aggregation, and Composition

Related Topic