202410242305 Status: #idea Tags: #software_engineering #design_patterns #computer_science #complexity # Deep modules are preferable over shallow modules ![[IMG_0630.png]] A programmer needs to understand a module’s interface (i.e. its name, the parameters it takes in; and what it does/outputs) in order to use it properly. This introduces complexity. However, a module also encapsulates & hides its implementation from the programmer (i.e. what it does and how it does it), which reduces complexity. Hence, we can see that to reduce complexity, we should keep module interfaces as simple & small as possible while having them capture as much functionality as possible. In other words, the module should be *deep* - it should a significant implementation behind a simple interface. This ensures that the usage of the module (i.e. the complexity required to understand its interface) is more than compensated by its implementation (i.e. the complexity removed by not needing to consider how the module is implemented). By contrast, shallow models have large interface and comparatively small internal functionality. In situations such as this, the module abstraction (whether it’s a class or a function) does not reduce the complexity of the overall application, and in some cases may even increase it. This concept is akin to chunking in expert learning. Expert chess players, for example, do not need to reason about every individual piece on the board because they have memorized patterns of common board positions and the implications of those patterns. Thus, their cognitive load is reduced and they can reason at a higher level of abstraction (at the board configuration level rather than the individual piece level). Similarly, deep modules reduces our cognitive load substantially by allowing us to chunk the codebase into easily understood method interfaces rather than their complex implementations. This allows us as programmers to operate at a higher level of abstraction and produce more complex systems. Key methods for creating deep modules include: 1. [[Information hiding in module design]] 2. [[General purpose modules tend to be deeper]] See also: [[Complexity in software development and design]] --- # References [[A philosophy of software design]]