202410242307 Status: #idea Tags: #complexity #software_engineering #design_patterns #object_oriented_programming # Pull complexity downwards when possible Generally, it is desirable to simplify the use of classes and functions as much as possible for a user. Hence, we should handle as much complexity as possible internally to our class or function implementations. This allows us to expose the simplest possible interface to the user, reducing the complexity of code that uses this interface. For example, configuration parameters have come very popular as a way to allow users flexibility to customize the functionality of modules on the fly. These work well when the module truly needs to be customizable - i.e., each use case needs a radically different value for that parameter, and it's best left up to the user to determine what that parameter is. However, if it is difficult but possible for us to determine the best parameter value automatically, we should do that and not expose the configuration parameter to the user (or expose it as an optional parameter where our automated value is the default value). This reduces the size of the class interface, thereby reducing the complexity of the code that uses this class. This can be taken too far (e.g. pulling all of the functionality of an application in a single class). Pulling complexity downwards makes sense if: 1. The complexity being pulled down is related to the class's existing functionality 2. Pulling the complexity down will result in simplification elsewhere in the application 3. Pulling the complexity down simplifies the class's interface See also: [[Complexity in software development and design]] --- # References [[A philosophy of software design]]