Previous | Beginning | Next
Notes
Hierarchies can often be the simplest ways of organising what we know, as [Jackson1995] observes under the heading of Arboricide. The word hierarchy is used a little more loosely in the following discussion, to include directed acyclic graphs (DAG) which are hierarchical, but not strict hierarchies. Where type defines the accessible operations and semantics of an object, a Type Hierarchy defines a classification relationship between types based on extension and substitutability. A Type Hierarchy may be realised through a number of mechanisms, including a Class Hierarchy or concatenation of generic requirements. Vertical delegation moves execution responsibility up and down a Class Hierarchy; commitment to implementation can be deferred or delayed down a hierarchy, or the knowledge of detail can be held toward the root. Exceptions are normally partitioned within a Class Hierarchy with respect to classification. An Object Hierarchy expresses a structure over which horizontal delegation acts, with significant objects cascading responsibility -- and being defined in terms of -- other objects that are identifiably more primitive. A common example of Object Hierarchy is Handle/Body [Coplien1992]. This can be mixed with Class Hierarchy to give Handle/Body Hierarchy (also known as Bridge [Gamma+1995]). A Function Hierarchy for distributing execution across elements may exist inside, outside or across class or source file boundaries. A Function Heterarchy supports a mix rather than flow of levels, possibly involving recursion, in call chains.
|
|
