Tjyylli

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.

So I did some googling.

here is the rule you quote:

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

https://www.appmarq.com/public/changeability,4576,Provide-accessors-to-Private-Fields

Its remediation:

Write a getter and setter to each private field

And a reference. Presumably for justification:

http://www.oracle.com/technetwork/java/javase/documentation/spec-136004.html
JavaBeans(TM) Specification 1.01 Final Release - paragraph 8.3 Design
Patterns for Properties p 55

However, if you check the reference it says nothing of the sort. It's all about how properties are implemented.

That coupled with the awful appmarq site which prevents text selection. Lead me to believe that the entire CAST audit is basically worthless.

The idea that every private field should be backing a property is ridiculous. Presumably what they mean is: "Use properties rather than public fields" or maybe "Beware of stateful objects!"

No, you don't seem to have missed anything. That audit sounds misguided, among other things it implies immutable objects, like String, are "against OO encapsulation concepts".