Modularity and deletion

In software, it's been recognized for a long time that modularity is a guiding principle of lasting value.

In practice, it usually makes sense to use the deletion test for modularity. It's a simple idea. To determine if a feature or aspect of a program is modular, just ask yourself this question: How many steps does it take to delete this feature? The fewer the steps, the more modular it is. If it takes only one step to delete a feature (usually by deleting a directory), then you can say that the design has maximum modularity.

File systems are hierarchical, with directories within directories. Given this basic fact of life, it's reasonable to have (as much as possible) a 1-to-1 mapping between the features of a program and directories/packages. If this is done, the deletion of a feature can sometimes correspond simply to the deletion of a directory. (This won't always be possible, but it's good to keep this idea in mind as a guideline.)

A counter-example to this idea is what some call a god class. By definition, a god class is related to a large number of features. God classes are the opposite of modular, and should usually be avoided. An example of a god class is a class that does nothing but hold a large number of String constants that have similar meaning. Such a style emphasizes an implementation detail (these are all similar Strings) instead of emphasizing feature modularity (String X is attached to feature Y). In this case, when you need to delete a feature, you usually also need to edit the god class in order to remove implementation details related to the feature.

Some aspects of a program may have a cross-cutting character, in the sense that most features are related to it somehow. Take the example of security in an application (controlling which users/roles execute which code).

There seem to be two choices for implementing security:

See Also :
Package by feature, not layer