September 4, 2019

Locality and Design Rationale

  —Minimize documentation while simultaneously communicating design intent and history.

I had occasion to read Data Abstraction and Hierarchy and was struck by the concept of locality described in the paper. This paper was presented in OOPSLA 87 and it’s focus is on using inheritance to define type heirarchies. It is the source of what became known as the Liskov Substituion Principle.

The notion of locality is enabled by abstraction supported by specification and encapsulation. The specification describes what the abstraction does, but omits any information about how it is implemented. Encapsulation guarantees that modules can be implemented and reimplemented independently. Encapsulation is related to the notion of information hiding described by Parnas.

The paper goes on to discuss the benefits of using abstraction to define type heirarchies. It includes an example of incremental design through the use of refining the type heirarchy as development progresses on the data type.

What’s interesting is that abstraction supported by specification and encapsulation during incremental design can be used to provide a design rationale.

The design rationale describes the decisions made at particular points in the design, and discusses why they were made and what alternatives exist. By maintaining the hierarchy to represent the decisions as they are made over time, we can avoid confusion and be more precise.

This provides insight on how to minimize documentation (specification), capture the evolution of the a design while communicating intent and history.