Java protected fields vs public getters

If there's going to be a public getter anyway, why would you want to expose the field itself more widely than absolutely necessary? That means it's immediately writable by subclasses (unless it's final to start with).

Personally I like all my fields to be private: it provides a cleaner separation between API and implementation. I regard the relationship between a superclass and a subclass as similar to that of a caller and callee - changes to the underlying implementation shouldn't break subclasses any more than they should break callers. The name of a field is an implementation detail which shouldn't impact other classes.

Admittedly my view is occasionally seen as somewhat extreme...

You should always program against the public API of a class, that is, use the public methods.

The reason is simple. Someday in the future, you or someone else might want to change the implementation. This should always be possible. If you rely on instance variable, you limit yourself.

Also, when accessing the variable, you can not control if that variable is read-only nor can you add checks when this variable is changed.

If you use setters/getters, you can allways add validation, checking etc later on. You can also only provide a getter to make a variable read only.

Direct field access is not preferred. Use public or protected setters and getters.

The getter need not be public - if you wan to hide the data from "outsiders", but give the data to subclasses, use protected

Some of Sun's recommendations on controlling access to fields are here. Note that making a field protected exposes it to the package as well, not only to subclasses. Generally, as stated at the link above, fields should be private unless there is a very good reason not to do so.

I would like to present you with some arguments protecting "protected" fields in Java: "You may favor accessing base class members using protected fields over public accessors in situation where you need to avoid value validation". However if this is not the case, then private fields with public accessors should be used, to compliment hermetization.

The principle of getters and setters is to provide validation to the values inputted and outputted to the class member. However, in OOP languages, we operate on objects not classes. Base class and specialized class represent a single object, that is why it is perfectly fine to access specific class members over protected field.

Consider the following abstract example with a car: - you have a base class Car and the derived class Porshe. - Car class may have field like engine, which value is not set in Cars constructor (maybe the type of engine is known only after object initialization) - You create a Porshe class object that contains some logic used to calculate engine type using some external data.

In this example, it is expected that engine field has a public getter, so car users know what engine the car has. However, there is no public setter as we expect car drivers not to temper with the engine! That is why, it is perfectly fine to make engine a protected field, so the Porshe class can set its value at some time in future.

Yes, some people will probably say "then use protected setter!". And I will repeat: in OOP languages we work with objects not classes. Single responsibility principle - yes, but as object not as class. If you say: "at some point if we use protected fields over 3 or 5 inheritance levels, it may be troublesome to understand what happens to the field if each class performs some operation with it". And then I answer: That is another antipattern - your object is probably too big at this point and voids Single Responsibility principle.

Accessing protected fields from a subclass is one of the ways that inheritance violates encapsulation. Using the public API is better for this reason.