Statement
Modules should be externally configurable.
Description
The ability to configure a module to it’s usage context increases our ability to reuse the module across contexts. Figure 1 illustrates External Configuration.
Figure 1: External Configuration
Implementation Variations
Different configuration files can be used for different contexts. The configuration file can be included in the module or included in a separate module, [...]
Statement
Create a facade serving as a coarse-grained entry point to the modules underlying implementation.
Description
Often times, configuring fine-grained modules can be a burden, especially when multiple fine-grained modules are typically used in conjunction but forces prevent module designers from combining the fine-grained module into a single coarse-grained entity. In these situations, a module facade can be [...]
Statement
Exceptions should be close to the class or interface that throw them.
Description
Sadly, dealing with exceptions in enterprise software systems is often an afterthought. But allocation of exceptions to modules has significant implications on the modularity, and more specifically the dependencies between modules, within our software system. Placing the exception close to a class that catches [...]
Statement
Modules should be independent of the runtime container.
Description
Modules with excessive runtime container dependencies are heavyweight modules that cannot execute outside the confines of the runtime container. A good example of a heavyweight technology is Enterprise JavaBeans (EJB), and the meteoric rise in popularity of lighter weight frameworks, such as Spring, are the direct result of [...]
Statement
Module relationships should be levelized.
Description
Levelized modules demands that module relationships be acyclic. Any cycles in module relationships therefore prevents levelization. There is a close relationship between levelized modules and physical layers, though the two are not the same. Physical layers aims to create one or more modules that are functionally equivalent to the typical layers [...]
Statement
Module behavior should serve a singular purpose.
Description
Cohesion is a measure of how closely related and focused the various responsibilities of a module are. In the worst case scenario, little emphasis is placed on the allocation of classes to modules. Instead, modules are assembled at random, and the likelihood that modules suffer from lack of cohesion [...]
Statement
Use factories to create a modules implementation classes.
Description
One of the challenges we face with abstract coupling is creation of the implementation class. A client class cannot create an implementation class if we want the two classes abstractly coupled. Figure 1 illustrates the Implementation Factory pattern.
Figure 1: Implementation Factory Pattern
Implementation Variations
Implementation Factory is often used with [...]
Statement
Place abstractions and the classes that implement them in separate modules.
Description
You create an abstract class or interface to help reduce coupling between classes. This offers the ability to create new implementations of the abstraction without impacting clients dependent on that abstraction. In this sense, abstract coupling allows you to add new classes to your system [...]
Statement
Depend upon the abstract elements of a module.
Description
Modules heavily depended upon have many incoming dependencies. In other words, you may have many modules that all depend on a single modules. On one hand, this is a good thing because you’ve managed to maximize reuse. But reuse has it’s challenges. If the modules you’re reusing heavily [...]
Statement
Each module should have a corresponding test module.
Description
Writing tests is one of the most important activities you should perform as a developer. Create a robust suite of tests has significant advantages, both long and short term. Short term, tests help you verify that the code you write does as you intend. Creating tests also helps [...]