What are the purposes of having private/protected members of a class/structure in object-oriented programming? What's the harm in having all members be public?
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.
The "private" members are meant to tell programmers that they should not access those members. They still can do so if they try, anyway.
Making a variable private "protects" its value when the code runs. At this level, we are not concerned with protecting it from other programmers changing the code itself. The point of so-called "data hiding" is to keep internal data hidden from other classes which use the class.
Which one we should use? We should use public access modifier if we want to make the method or property visible from anywhere, other classes, and instances of the object. Use the private access modifier if you want to make the method or property visible in its own class only.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With