Design Concept - Encapsulate Classes and Packages

Classes should provide a simple public interface that does not allow binding to its implementation. That is, client code should only be able to access the class's public interface member functions and should not be able to directly access its member data and private member functions. We say that such classes are encapsulated.

The implementation of a class is subject to change every time we fix latent errors or add functionality to the class. That will break the design of any client that binds to its implementation, causing a cascade of consequential changes. The class's public interface changes much less frequently, so encapsulation is a mechanism to minimize the affects of change.

Exactly the same statements can be made for packages. A package is similar to a class that only supports one instance. Its global functions and global data act like member functions and member data of a class. We can make package global data private by qualifying its declaration with the keyword static. Similarly its global functions are public unless they are also qualified with static. Of course packages can host classes, but classes can also host nested classes, so the analogy holds in this case too.

• All public functions (member or global) should be have few arguments, provide conceptually simple operations - which may well be complex internally - and disclose no design details. Returning a pointer from a function requires the user to know enough about the function's design to know whether to delete the pointer when no longer needed, for example, so try not to do that. Another example is passing a function argument by non-constant reference. That makes possible the modification of that argument in the caller's scope. You have to know some design details to understand the implications of that, so favor passing arguments by constant reference or value. Like most design rules there are exceptions to these, and you often encounter them when building linked data structures and clone() functions.
• A designer may wish to partition a function into several parts, some of which may require a lot of design knowledge to use safely. These should be private to an outer function which can be safely used by clients without any such knowledge.
• Data should almost never be made public. A change of name or type of any variable will require changes to all code that uses the variable directly. Keeping data private isolates those changes to the class defining the data instead of propagating throughtout a project. This means, for example, that only the designer of the class needs to know about the change.
• The only thing that never changes in a project is the constant flow of changes. Change happens because a design is incomplete or immature, because requirements change, because of changes in code a package depends on, because of latent errors, and inadequate performance margins.

  One of the most important requirements for a professional developer is to write code that is robust against change. Learning to do that is one reasone you are taking this course. The first step is to favor well encapsulated classes.

• Note: A string class example

Conclusions for Encapsulate Classes and Packages: