CODEWITHSUNDEEP
javaoopencapsulation
SuperDisk
SuperDisk

Reputation: 2840

Java: When NOT to use `private`

Since it's regarded bad OO practice to have public variables in a class (instead, use getters and setters) then why not use private on all variables? Why does Java even permit using public if it's bad practice?

(This doesn't apply to functions, obviously)

Upvotes: 4

Views: 281

Answers (7)

syb0rg
syb0rg

Reputation: 8247

It's a matter of managing complexity.

A public member can be accessed from outside the class, which for practical considerations means "potentially anywhere". If something goes wrong with a public field, the culprit can be anywhere, and so in order to track down the bug, you may have to look at quite a lot of code.

A private member can only be accessed from inside the same class, so if something goes wrong with that, there is usually only one source file to look at. If you have a million lines of code in your project, but your classes are kept small, this can reduce your bug tracking effort by a lot.

Another advantage is related to the concept of coupling. Some answers forgot to mention this.

I'd say make everything private by default, and then expose only those parts that absolutely have to be public (or just use getters and setters). The more you can make private, the better.

Upvotes: 0

Andy Thomas
Andy Thomas

Reputation: 86391

Access control of variable fields is not the only concern.

Consider simplicity. Java has a single default for access control of all types. This is easier to learn than having different access rules for different types.

Consider usability for new users. If everything were private by default, new users would be more likely confused about why something could not be accessed.

Finally, note that "getters and setters" are not always the appropriate alternative to public fields. Some fields should not be modified or even accessed outside the class.

[EDIT] There's also a historical reason behind the choice. The earliest versions of Java, then known as "Oak," had no private access. The default, and most-restricted access was package-protected. (Reference: this 2002 Java newsletter, citing the Oak 0.2 manual.)

Upvotes: 2

Arsen Alexanyan
Arsen Alexanyan

Reputation: 3141

I think this is good to have this possibility (excluding static final constants), because You can use this to solve some problems quickly(instead of defining getters and setters), you just need to be careful here by breaking encapsulation rules.

Upvotes: 0

Bohemian
Bohemian

Reputation: 424993

It's about where you want to publish the field.

For public fields, you could safely do it for final fields, like constants:

public static final ...

And final fields:

public final ...

like the length field in java arrays. Although the convention is to provide a accessor method (a getter) in preference to making a field public.

Use protected fields when you want to publish the field to subclasses.

Use default visibility (ie not specified) when you want to publish the field to other classes in the same package.

Upvotes: 0

asteri
asteri

Reputation: 11572

Having a public or private field is a design decision. The language itself is supposed to enable programmers to make their own design decisions, not enforce a design that the developer or team may not necessarily want to implement.

The more flexible the language, the more powerful it is. It's up to the project manager, the team, or the individual developer to determine the most appropriate way for a field to be accessed.

Upvotes: 4

millimoose
millimoose

Reputation: 39950

I guess a good part of the reason is "C++ did it that way". Different languages disagree on this issue, so it's obviously not the only sensible choice. E.g. Python has everything public and trusts you to follow a library's documentation, while Ruby only has private fields.

Upvotes: 0

Petar Minchev
Petar Minchev

Reputation: 47373

A public static final variable is a good reason for example. Like a constant.

Upvotes: 8

Related Questions