Breaking up the Monolith

(main page)

Breaking up the Monolith is a collection of essays on C++ techniques for writing and working with C/C++ third-party libraries effectively, efficiently and with minimal coupling.

This page contains a glossary of terms used within the book.

• Abstraction Dissonance
  The condition whereby client code is written using units of currency that exist at a higher level of abstraction than those used by the libraries/APIs in terms of which the client code is written.
  
  
• Contract Enforcement
  The act of verifying actual conditions against expected conditions, and reacting if they differ.
  
  Contract enforcements can be undertaken at compile time and at runtime.
  
  
• Contract Programming
  The practice of specifying and, optionally, enforcing contracts within the limitations imposed by a given language, operating environment, and design and development constraints.
  
  
• Correctness
  The consistency of its implementation with its specification.
  
  
• Defect
  An aspect of a software system that may cause the system to depart from its intended behaviour.
  
  A defect is the potential for a fault.
  
  If the defect is downstream from the design phase, then it will represent a design violation, and may be policed using contract programming enforcements.
  
  
• Enforcement Indivisibility, The (Rule)
  Each enforcement should test a single condition of a contract.
  
  
• Error
  A wrong decision made during the development of a software system.
  
  
• Failure
  The condition whereby a software system does not provide the functionality prescribed by its specification
  
  Failures may be caused by failure in design or in coding.
  
  
• Fault
  The event of a software system behaving in conflict with its design.
  
  A fault is the reification of a defect.
  
  
• Header-Only
  A C and/or C++ library all of whose elements are contained in include (header) files, requiring no link-time dependencies.
  
  
• Irrecoverability (Principle)
  The principle of irrecoverability states: It is not possible for a software system to operate in accordance with its design if any component part of that system has violated its design. A system executing in such a state must be stopped immediately.
  
  
• Non-redundancy (Principle)
  The principle of non-redundancy states*: Under no circumstances shall the body of a routine ever test for the routine's precondition.
  
  
• Removability (Principle)
  When applied to contract enforcement, the principle of removability states: A contract enforcement should be removeable from correct software without changing the (well-functioning) behaviour.
  When applied to logging, the principle of removability states: It must be possible to disable any log statement within correct software without changing the (well-functioning) behaviour.
  
  
• Shim (Concept)
  An unbounded set of function overloads that generalise between (aspects of) conceptually related but physically unrelated types. A shim is defined by four characteristics: Name, Intent, Category and Ostensible Return Type.
  
  
• Shim, Characteristic: Category
  The intent, behaviour and constraints on the use of a shim. Shim categories can be fundamental (Attribute, Control, Conversion & Logical) or composite (combinations of two or more shim categories).
  
  
• Shim, Characteristic: Intent
  The common purpose of all functions constituting the shim.
  
  
• Shim, Characteristic: Name
  A fully-qualified name, consisting of namespace name + function name, that is shared by all function overloads comprising the shim.
  
  
• Shim, Characteristic: Ostensible Return Type
  The type to which the return type of all overloads of a given shim are implicitly convertible.
  
  
• Shim, Concept (composite): Access
  
  
  
• Shim, Concept (composite): Action
  
  
  
• Shim, Concept: Attribute
  
  
  
• Shim, Concept: Conversion
  
  
  
• Shim, Concept: Control
  
  
  
• Shim, Concept: Logical
  
  
  
• Shim, Degenerate
  The degenerate form of a shim is the overload (or template) whose argument is equivalent to the ostensible return type of the shim; only attribute and access shims have degenerate forms.
  
  In all cases, the degenerate form of a shim function does no allocation or conversion (other than cv-qualifier conversion).
  
  
• Type Tunnel (Pattern)
  A Type Tunnel describes the situation where a group of physically-unrelated types may be tunneled through an extensible adaptation layer and presented in unified form to an underlying layer for manipulation as a whole. It consists of the following:
  1. a generic, extensible interface layer, used in client code, which can interact with heterogeneous types, and
  2. a tunnel mechanism, which translates between the heterogeneous types expressed in the client code into the type understood by
  3. a concrete API layer, which manipulates a single concrete type.
  
  Libraries that employ the Type Tunnel pattern include FastFormat, Pantheios and VOLE. All three use N-ary function templates as the interface layer. The first two use shims as the tunnel mechanism, whereas VOLE uses conversion constructors.
• Unit of Currency
  The primary physical type with which client code represents a given conceptual type. The primary physical type by which a component or API communicates a given conceptual type to its client code.
  
  

References

• [Meyer97] Object-Oriented Software Construction, Bertrand Meyer, Prentice-Hall Professional, 1997