User Tools

Site Tools


modulehierarchy

Module Hierarchy

Modules are containers for functions. Their purpose is to improve productivity in the long run. The use of modules influences understandability, testability, re-use, and deployment.

Modularization is concerned with increasing the lifetime of software, not improving any runtime quality.

Modules accomplish this primarily by

  1. grouping functions according to some similarity under a name (abstraction by aggregation),
  2. hiding details of how grouped functions are structured into a hierarchy and share data behind an interface (abstraction by integration).

And finally interfaces can be extracted from modules as standalone contracts (abstractions by distillation). Abstract classes and explicit interfaces describe an essence which then can be implemented in different ways (polymorphism).

Since the number of functions can grow indefinitely in a code base, not just one level of modules is sufficient to do the job. Modules can be nested (classes within classes), but most of all they come as a hierarchy, i.e. in different kinds.

Flow-Design works with the following hierarchy of modules listed from “small” to “large”, from fine grained to coarse grained:

Note: Namespaces in most languages don't belong to the module hierarchy because they lack the ability to hide details of the functions (or modules) aggregated. Thus namespaces are considered orthogonal to the module hierarchy as a separate means for abstraction by aggregation.

modulehierarchy.txt · Last modified: 2018/07/21 10:06 by fdadmin