Statement
Perform the build in accordance with module levelization.
Description
An automated and repeatable build is a critical aspect to most successful development projects. First and foremost, an automated and repeatable build forces you to integrate early and integrate often, so you’re guaranteed to always have a system that works. Of course, there are a couple of rules [...]
Statement
Make a modules published interface well-known.
Description
Java provides two levels of visibility for classes and four levels of visibility for methods and attributes, all of which are discussed in detail in MinimizeVisibility. For components, however, no additional visibility modifiers are available, providing some limitations on how well you can insulate classes and behaviors within a component. [...]
Statement
Modules should be as independently deployable as possible.
Description
For a module to be independently deployable, it cannot have any outgoing dependencies on any other module. Some module are naturally more independent than others. For instance, it would be relatively easy to create an indepdent module to perform various mathematical and statistical functions, mainly because there are [...]
Statement
Module relationships must not violate logical layer relationships.
Description
It’s common knowledge that when designing systems of any degree of complexity, the presentation, business logic, and data access should be separated into distinct layers. There are two important considerations when separating the layers.
Each layer should be responsible for a functional aspect of the application. The most common [...]
Statement
Emphasize reuse at the module level.
Description
One of the oft cited benefits of object oriented development is reuse. Mostly, we’ve failed miserably in achieving any degree of reuse that is directly attributable to objects. A large part of this failure is very likely because using objects does not guarantee reuse, but actually requires a significant amount [...]
Statement
Module relationships should be uni-directional.
Description
When you define a relationship between two system components, their coupling is increased. Some degree of coupling is a necessary simply because components need to work together with each other to accomplish some task. But certain types of coupling should be avoided. The diagram at right in Figure 1 illustrates a [...]
Statement
Design module relationships.
Description
A relationship between two modules exists when a class within one module imports at least a single class within another module. In other words:
If changing the contents of a module, M2, may impact the contents of another module, M1, we can say that M1 has a Physical Dependency on M2. [JOUP02]
In Figure 1, [...]