Encapsulation. I.e. hiding the implementation of your class data. This allows you to change it later, without breaking all client code. E.g. if you have
class MyClass {
public int foo;
}
your clients may write code like
MyClass bar = new MyClass();
bar.foo++;
now if you realize that foo
should actually be a double rather than int, you change it:
class MyClass {
public double foo;
}
and the client code fails to compile :-(
With a well designed interface, the change of the internals (private parts) may even include turning a member variable into a calculation or vice versa:
class Person {
public String getName();
public String getStreetAddress();
public String getZipCode();
public String getCountryCode();
public int hashCode();
}
(using String properties for the sake of simplicity - in a real world design some of these would probably deserve to have their own type.)
With this design, you are free to e.g. introduce an Address
property internally, which would contain street address, zip code and country code, and rewrite your accessors to use the fields of this private member instead, without your clients noticing anything.
You could also decide freely whether to calculate the hash code every time, or to cache it into a private variable in order to improve performance. If that cache field was public, however, anyone could change it, which could ruin hash map behaviour and introduce subtle bugs. So encapsulation is key in guaranteeing the consistency of the your object's internal state. E.g. in the above example, your setters can easily validate the zip code and country code, to prevent setting invalid values. You can even ensure that the zip code format is valid for the actual country, that is, ensure a validity criteria spanning multiple properties. With a well designed interface, you can enforce this binding by e.g. providing only a setter to set both properties at the same time:
public void setCountryCodeAndZip(String countryCode, String zipCode);
However, with public fields you simply don't have these choices.
A special use case for private fields is immutable objects; this is very common in e.g. Java, examples are String
and BigDecimal
. These classes have no public setters at all, which guarantees that their objects, once created, will not change their state. This enables a lot of performance optimizations, as well as makes them easier to use in e.g. multithreaded programs, ORM etc.