Programming Scala, 3rd Edition

Chapter 15. Visibility Rules

Encapsulation of information in modules is a hallmark of good software design. Used well, it exposes logically consistent abstractions to users and hides implementation details. The latter is necessary to prevent unwanted access to internal details and to enable easier evolution of those details without impacting users. This chapter discusses Scala’s visibility rules for specifying encapsulation.

Many languages provide a few scopes of visibility for definitions, often tied to subtype relationships (object-oriented inheritance). Java is typical, with four visibility scopes:

Public

Visible everywhere

Protected

Visible only inside the type and subtypes

Private

Visible only inside the type where declared or defined

Default package

Visible to any other type in the same package

Scala changes Java’s visibility rules in two major ways. First, public is the default and there is no public keyword. Second, protected and private can be qualified by a scope, either a type or a package; for example, protected[mypackage] for scoping to some package mypackage.

The qualified scopes are underutilized in Scala code, in my opinion. They give library developers careful control over visibility inside and outside a library’s API.

Scala 3 adds another tool for fine-grained visibility control, export clauses, which we explored in “Export Clauses”.

Public Visibility: The Default

Scala uses public visibility by default. It is common to declare members of types private ...