Complexity Simplified by Modularity
When designing a system, certain concepts will naturally sit together. By placing these into shared modules, a certain amount of separation can be achieved that is independent of the layering discussed so far. Functionality can be split into classes, and these classes can be grouped in packages or components. By reducing the dependencies between the classes and packages, this functionality can be used by different parts of the application. By defining and maintaining interfaces between classes and packages, the actual implementation of a class can be replaced without requiring a change to other classes that depend on it. The Unified Modeling Language (UML) diagram in Figure 1.4 shows this type of decomposition.
Figure 1.4. Modularity.
Object-oriented (OO) modeling promotes modularity to a large extent. Objects encapsulate their data or state and offer functionality through their interfaces. If designed correctly, the dependencies between different objects can be minimized. This reduction in dependency means that the objects are loosely coupled. Loosely coupled systems tend to be easier to maintain and evolve.
Object-oriented programming tried to improve maintainability with encapsulation and to aid system design with a definition of specific classes for specific roles, providing coherent groups of functionality. This significantly improved the previously poorly designed monolithic code and made things more maintainable and flexible. However, it was language-specific (Java, C++, and Smalltalk) and so did not make deployment or integration easier.
Although it is not the whole solution, you have some useful tools for modularizing your applications in Java:
A Java class is a way of adding modularity by housing all state and behavior belonging to an entity into one part of the design.
A Java package is another way of using modularity to house all classes and interfaces that belong together to perform a specific set of functions.
What you then need is a way of going beyond simple objects to provide more coarse-grained packages of functionality that can be glued together to create custom applications. To be correctly glued, these packages must conform to certain rules that are defined by a framework. This leads us to components.
Component Technology
A component is a unit of functionality that can be used within a particular framework. Component frameworks have evolved to provide support for simplified application development. When using a component framework, a container provides the components with certain standard services, such as communication and persistence. Because standard mechanisms are used for component definition and inter-component communication, it becomes possible to write tools that examine components and display their information to an application writer. A developer can then use the tool to drag and drop these components into his or her application. This can be seen in the typical GUI interface builder environments, such as Visual Basic, or the Java equivalents, such as Borland's JBuilder and IBM's Visual Age for Java.
The component principle applies to non-visual components also. Whole distributed applications can be created from components. One of the benefits of distributed component frameworks is that they can provide language independence. Using CORBA, for example, components written in C can communicate with those written in OO languages such as Java and Smalltalk.
In Java, there are several component frameworks from which to choose. The J2EE platform uses components extensively to provide modularity within the layers of an application. As such
A Java component is yet another way of using modularity to house all packages required to perform a specific task. In the 3-tier environment, for example, the functionality of the Data Access Logic layer would be split into multiple components.
A component will publish its interface defining the functionality it offers. This functionality can then be used by the application itself or by other components.
Benefits of Modularity
If separate parts of the design can be identified, the most appropriate developers can be tasked with the implementation simultaneously. Some components can also be purchased from third parties and integrated quite easily because all components will conform to the framework. This brings down the time to market and is, therefore, a significant cost benefit.
The system is more maintainable if identifiable parts are capable of being upgraded and re-implemented without hindering the existing running of the system. With modularity comes the possibility of loose coupling, which means the system itself is extendable without introducing dependencies. If a module has loose coupling, its maintenance is simpler.
Using components within layers allows you to further modularize the functionality in those layers.