Cover by Alex Payne, Dean Wampler

Safari, the world’s most comprehensive technology and business learning platform.

Find the exact information you need to solve a problem on the fly, or go deeper to master the technologies and skills you need to succeed

Start Free Trial

No credit card required

O'Reilly logo

Visibility Rules

Note

For convenience, we’ll use the word “type” in this section to refer to classes and traits generically, as opposed to referring to member type declarations. We’ll include those when we use the term “member” generically, unless otherwise indicated.

Most object-oriented languages have constructs to constrain the visibility (or scope) of type and type-member declarations. These constructs support the object-oriented form of encapsulation, where only the essential public abstraction of a class or trait is exposed and implementation information is hidden from view.

You’ll want to use public visibility for anything that users of your classes and objects should see and use. Keep in mind that the set of publicly visible members form the abstraction exposed by the type, along with the type’s name itself.

The conventional wisdom in object-oriented design is that fields should be private or protected. If access is required, it should happen through methods, but not everything should be accessible by default. The virtue of the Uniform Access Principle (see When Accessor Methods and Fields Are Indistinguishable: The Uniform Access Principle) is that we can give the user the semantics of public field access via either a method or direct access to a field, whichever is appropriate for the task.

Tip

The art of good object-oriented design includes defining minimal, clear, and cohesive public abstractions.

There are two kinds of “users” of a type: derived types, and code that works ...

Find the exact information you need to solve a problem on the fly, or go deeper to master the technologies and skills you need to succeed

Start Free Trial

No credit card required