|Ada 95 Quality and Style Guide||Chapter 4|
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).
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;
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.
The most prevalent objection to this guideline usually involves performance penalties. See Guideline 10.7.1 for a discussion about subprogram overhead.
|< Previous Page||Search||Contents||Index||Next Page >|