Information Hiding/Accessibility

In practice, objects often restrict access to some of their features (attributes or methods). Such restriction is known as information hiding. In a well-designed object-oriented application, a class typically publicizes what its objects can do—that is, the services the objects are capable of providing, as declared via the class’s method headers—but hides the internal details both of how they perform these services as well as of the data (attributes) that they maintain internally in order to support these services.

Public Accesibility

When a feature is declared to have public accessibility, it’s freely accessible from client code using dot notation.

Private Accesibility

When a feature is declared to have private accessibility, on the other hand, it’s not accessible outside of the class in which it’s declared—that is, we may not use dot notation to access such a feature from client code.

Publicizing Services

As it turns out, methods of a class are typically declared to be public because an object (class) needs to publicize its services so that client code may request these services. By contrast, most attributes are typically declared to be private (and effectively “hidden”), so that an object can maintain ultimate control over its data.

When a client object A asks another object B to perform one of its methods, A doesn’t need to know the behind-the-scenes details of how B is doing what it’s doing; object A needs simply to trust that object B will perform the “advertised” service.

Accessing Private Features from Client Code

Declaring Accessor Methods

The Power of Encapsulation Plus Information Hiding

Assume that you’ve just met someone for the first time, and wish to know his name. One way to determine his name would be to reach into his pocket, pull out his wallet, and look at his driver’s license—essentially, accessing his private attribute values without his permission! The more socially acceptable way would be to simply ask him for his name—akin to using his getName method—and to allow him to respond accordingly. He may respond with his formal name, or a nickname, or an alias, or he may say, “It’s none of your business!”—but the important point is that you’re giving the person (object) control over his response.

• Preventing unauthorized access to encapsulated data
• Helping to ensure data integrity
• Limiting “ripple effects” that can otherwise occur throughout an application when the private implementation details of a class must change

Using Accessor Methods from Within a Class’s Own Methods

To avoid ripple effects.

Exceptions to the Public/Private Rule

Exception #1: Internal Housekeeping Attributes

An attribute may be used by a class strictly for internal housekeeping purposes. For such attributes, we needn’t bother to provide public accessors.

Exception #1: Internal Housekeeping Methods

Some methods may be used strictly for internal housekeeping purposes, as well, in which case these may also be declared private rather than public.

Exception #3: “Read-Only” Attributes

If we provide only a “get” method for an attribute, but no “set” method, then that attribute is rendered effectively read-only from the perspective of client code.

Exception #4: Public Attributes

On rare occasions, a class may declare selected attributes as public for ease of access; this is only done when there is no business logic governing the attributes per se.