CODEWITHSUNDEEP
javaoopencapsulation
Matthieu Napoli
Matthieu Napoli

Reputation: 49703

Are "protected" and "public" visibilities useless for class fields?

It is considered best practice for encapsulation to use private fields with accessors (getters and setters), instead of protected and public fields.

So, by following this best practice, we never use protected and public anymore. Have they become useless, or else what are their use cases?

The only thing I can think of is for public static final attributes (i.e. class constants).

Note: this is the case at least strongly in the Java world, but the question stands for all languages.

Upvotes: 5

Views: 847

Answers (7)

Pablo Grisafi
Pablo Grisafi

Reputation: 5047

Best practices can change over time.
I can think in two use cases for public fields, both somehow controversial.
Adam Bien says in this post that if you are using a DTO, you may not use private + getter + setter but only public fields. This way you are sure that data is transported as is, without any changes. But in the same line he adds that this will cost you lots of meeting explaining why you do it that way...

Another use for non constant public fields is using public final fields (initialized in constructor) to ensure immutability. Making your classes like

public Person{
    public final String lastName;
    public final String firstName;
    public Person(String firstName, String lastName){
        this.firstName = firstName;
        this.lastName = lastName;
    }
}

is some sort of a new best practice, advised in places like codemonkeyism.

But unless you are the absolute owner of the code and/or you can force new standards to be fulfilled, you should keep avoiding the use of public/protected fields...

Upvotes: 2

trutheality
trutheality

Reputation: 23455

"Useless" is in the eye of the beholder. Some "best practices" are overrated:

Suppose you want the equivalent of a C-style struct, basically a methodless class that just holds a bunch of data. It's certainly more convenient and readable to just have a class with public fields than a class with a bunch of getters and setters.

Suppose you want access to a value that never changes (like an array's length) a public final field is perfect for that. Also, it's extremely common to have a "Constants" class which holds nothing but public static final fields. There are countless standard library classes with public static final fields. Actually, almost every time you want a public constant it's the thing to use.

protected fields are pretty rare though, AFAIK. You really need to be planning to have a subclass to have the foresight and the need to use protected.

Upvotes: 1

kasavbere
kasavbere

Reputation: 6003

In engineering "best practice" means general guidelines. Using getters and setters is not best in all cases. For example, if you are creating a BST, then it is a lot simpler to declare the fields of the Node class public (i.e. data, left, right); the methods in the BST are then simpler to read and write. Again because direct access is much simpler in some instances, you may use protected to give direct access to subclasses while denying access to the public..

Upvotes: 1

stefan bachert
stefan bachert

Reputation: 9624

public, private, protected and package are not limited to fields.

There are a lot useful applications to be used on methods and constructors.

However, it will be inconsistent to try to limit fields only to scope private since java is not able to do so in the case of nested/inner classes.

Upvotes: 0

Pau Kiat Wee
Pau Kiat Wee

Reputation: 9505

Sometime there are internal constant which only allow subclass to use, then you might need protected modifier instead of creating getter for those constants. This applied to fields that allow subclass directly access, which does not expose to outside.

Upvotes: 0

manub
manub

Reputation: 4100

Well, I still see a lot of public static final fields, which make sense to me - as they're constants. Apart from that (and some protected cases - but need always to be careful), I think it's very rare to see that (and you should have some good reasons I can't think of for making a field public and not final at least).

However, I also think that use of getter/setters should be limited to the minimum indispensable - I saw in the past people putting getters on every field - even when not needed.

Upvotes: 0

Louis Wasserman
Louis Wasserman

Reputation: 198471

In terms of internal fields? Yes, they're useless in many cases. (Sometimes protected is acceptable if you expect there to be subclasses, though.) And public static final attributes are also perfectly okay.

That said, public and protected methods are absolutely necessary.

Upvotes: 3

Related Questions