Chapter 4: Program Structure - TOC - 4.1 HIGH-LEVEL STRUCTURE

4.1.5 Packages

guideline

Use packages for information hiding.

Use packages with tagged types and private types for abstract data types.

Use packages to model abstract entities appropriate to the problem domain.

Use packages to group together related type and object declarations (e.g., common declarations for two or more library units).

Encapsulate machine dependencies in packages. Place a software interface to a particular device in a package to facilitate a change to a different device.

Place low-level implementation decisions or interfaces in subprograms within packages.

Use packages and subprograms to encapsulate and hide program details that may change (Nissen and Wallis 1984).

example

Reading the names and other attributes of external files is highly machine dependent. A package called Directory could contain type and subprogram declarations to support a generalized view of an external directory that contains external files. Its internals may, in turn, depend on other packages more specific to the hardware or operating system:

package Directory is

   type Directory_Listing is limited private;

   procedure Read_Current_Directory (D : in out Directory_Listing);

   generic
      with procedure Process (Filename : in String);
   procedure Iterate (Over : in Directory_Listing);

   ...

private

   type Directory_Listing is ...

end Directory;

---------------------------------------------------------------

package body Directory is

   -- This procedure is machine dependent
   procedure Read_Current_Directory (D : in out Directory_Listing) is separate;


   procedure Iterate (Over : in Directory_Listing) is
      ...
   begin
      ...

      Process (Filename);

      ...
   end Iterate;

   ...

end Directory;

rationale

Packages are the principal structuring facility in Ada. They are intended to be used as direct support for abstraction, information hiding, and modularization. For example, they are useful for encapsulating machine dependencies as an aid to portability. A single specification can have multiple bodies isolating implementation-specific information so other parts of the code do not need to change.

Encapsulating areas of potential change helps to minimize the effort required to implement that change by preventing unnecessary dependencies among unrelated parts of the system.

notes

The most prevalent objection to this guideline usually involves performance penalties. See Guideline 10.7.1 for a discussion about subprogram overhead.