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, whereas tightly coupling configuration to the module prohibits reuse. External configuration allows a module to be reconfigured across environments, and even within it’s existing environment, without demanding redeploying the module.

Statement

Create a facade serving as a coarse-grained entry point to the modules underlying implementation.

Description

We create fine-grained and lightweight modules to increase module reuse. Unfortunately, fine-grained modules can also be difficult to use because the user must understand the API of several different modules and use them in conjunction with each other to accomplish a particular task. Additionally, lightweight modules must also be configured to an environmental context. Because of this, fine-grained and lightweight modules are generally more difficult to use. A Module Facade is useful to provide a higher level API that coordinates the work of a set of fine-grained modules.

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 it will often cause a cyclic dependency between the module containing the class that throws the exception and the module containing the class that catches the exception. Exceptions should always be placed in a module closer to the class that throws the exception than a module closer to the class that catches the exception.

]]> http://www.kirkk.com/modularity/2009/12/colocate-exceptions/feed/ 0 http://www.kirkk.com/modularity/2009/12/container-independence/ http://www.kirkk.com/modularity/2009/12/container-independence/#comments Mon, 28 Dec 2009 19:28:50 +0000 kirk knoernschild http://www.kirkk.com/modularity/?p=355 For the full description, implementation variations, consequences, and detailed sample, see Page 150 in Java Application Architecture.

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. Lightweight modules with no container dependencies have significant advantages.

Statement

Module relationships should be levelized.

Description

Levelized modules demand that module relationships be acyclic. Any cycles in module relationships therefore prevents levelization. To levelize modules relationships, there are several steps.

Statement

Module behavior should serve a singular purpose.

Description

There are two key elements that affect module cohesion. These follow:

• The rate at which the software entities within a module change.
• The likelihood that the software entities within a module are reused together.

Based on these statements, it’s easy to draw the following conclusion:

• Classes which change at different rates belong in separate modules.
• Classes that change at the same rate belong in the same module.
• Classes not reused together belong in separate modules.
• Classes reused together belong in the same module.

Unforunately, while logical, these general statements do not always apply.

Statement

Use factories to create a modules implementation classes.

Description

One of the challenges we face with Abstract Modules is how the object relationships are established at runtime. A class dependent on an abstraction should avoid referencing any of the implementing classes, otherwise anytime a new implementation class is defined, the class dependent on the abstraction also needs to be changed.

If a class depending on an abstraction must be changed when creating a new implementation of the abstraction, the design is flawed.

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 without modifying existing classes, and it does so by reducing the dependency relationship between classes.

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 module. 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 require a change, the ramifications of that change can ripple throughout all dependent modules. Changing a heavily reused module can be quite a maintenance headache. Abstract Modules helps you deal with this dilemma.

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 you design your system. Since classes should be independently testable, a natural by-product of test driven development is that your classes will exhibit lower degrees of coupling. Testing classes independently is valuable, but it’s also valuable to test the integration aspect of multiple classes or modules.