202410242307 Status: #idea Tags: #complexity #software_engineering #design_patterns #object_oriented_programming # Information hiding in module design Information hiding involves burying specific methods and variables inside a class (or function) which are not relevant to the user of the class. This ensures that we minimize the size of the module's interface, while maximizing the depth of its implementation. Information hiding generally involves making classes bigger than they were before, as we build more functionality into the class in order to hide details from end users. Two examples of issues that can be improved with information hiding through increasing the size of classes are: 1. **Information leakage** - this occurs when two or more classes rely on information or a design decision that is external to those classes. This commonly occurs when variables are exposed in class's or method's interface - the information from inside the class must then inherently be leaked to the code that is using that class. Hence, simplifying the class interface to be as minimal as possible will reduce information leakage (and thus improve information hiding). Another example is two or more classes that operate on files with an expected file format. In this case, we have *implicit* leakage, where the information is not in any of the classes's interfaces. In this situation, it can reduce complexity to centralize methods relating to this file format into a single class. Another alternative to mitigate information leakage is to pull the leaked information out of all of the affected classes and create a new class that encapsulates just that information. 2. **Temporal decomposition** - many times, programmers will decompose the steps of an operation into classes. For example, when receiving an HTTP request, we might use one class to read the request and another class to parse the request since these two steps happen sequentially. However, this results in a significant amount of repeated work, as you cannot read an HTTP request without doing most of the work of parsing it. Hence, we could simplify things by making the temporal steps part of the same class. In general, when designing modules, we should focus on the information needed to complete each task and group together functionality that requires the same information. We should *not* focus on the order of tasks to decide when to separate classes. See also: [[Complexity in software development and design]] --- # References [[A philosophy of software design]]