Java Encapsulation – Should a Class Provide Public Mutators for Private Fields?

encapsulationgettersjava

I work on refactoring an Java application based on a CAST audit. One of the criterion says that

To respect OO encapsulation concepts, private fields should always be
accessed through accessors

So far, so good. However, the audit highlights all private fields in the class that have no mutators, regardless how they are being used.

In my case, these fields are only accessed from inside the class.

I could provide private accessors for all of them, but for readability purposes, I do not think it is a good idea. Furthermore, I do not see how providing private getters for private attributes enhances OO encapsulation.

I could also provide public mutators for all fields. I have seen it done in many applications. Come to think of it, most IDEs provide a functionnality that automatically generates public mutators for all of the class attributes…

But I wonder, is it not against the very principle of encapsulation to provide public accessors for private attributes that are only meant to be used inside the class?

EDIT : my question is not about the use of accessors inside their own class. It is about the relevance of providing public accessors for all private fields in the class, regardless they are used outside the class or not.

Best Answer

While there are few hard and fast rules in software design and development, there's a school of thought that mutators/getters/setters for every attribute of a class are an anti-pattern or at least not a good practice for OOP.

At least in some measure, the widespread use of getters/setters seems to have been heavily influenced by JavaBeans, which are not particularly object oriented, or at least not a general case of object orientation. Some people went as far as to claim that getters/setters were "evil" (in 2003!) or "considered harmful".

I wouldn't go as far, but I do think many getters/setters tend to weaken or sidestep guidelines such as Tell, Don't Ask and encapsulation. If an attribute is an implementation detail, an internal of the class, why should it be exposed through its interface?

Getter/setters are in some cases also a historical "artifact" of some persistence frameworks that used to require them (or at least encourage their use) to persist/load objects to and from the datastore. In that case, a technical detail ended up encouraging bad OO design.

With all this in mind, I think one thing can be said: no, a class should NOT provide public mutators for all its private fields. It might be necessary in some cases, but as a general principle it's not correct.

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