Invocation of peripheral services in Java

Encode QR Code in Java Invocation of peripheral services

} ... More operations similar to above addressing multiple concerns public void save(<persitance storage parameters>) { ... } public void load(<persitance storage parameters>) { ... } }

There are a few observations we can make from this code snippet: The log stream and cache update status do not seem to be related to the core requirements of this class; they are part of the class only to support the systemlevel requirements of the logging and caching concerns. The someOperation1() method s implementation seems to be doing a lot more than just the core operation. It is taking care of peripheral concerns: logging, authentication, multithread safety, contract validation, cache management, and so forth. It is not clear if save() and load(), which are performing persistence management, should be in the class at all. A real system would consist of many classes similar to the above. Many would address the same peripheral concerns addressed in this class, such as authorization and logging. Therefore, while we may have had a good understanding of different crosscutting concerns and their separation during the design phase, the implementation paid almost no attention to preserving the separation.

1.4.1 Symptoms of nonmodularization We can broadly classify the symptoms of nonmodularization into two categories: code tangling and code scattering. If you see these symptoms in your system, it is most likely due to the conventional implementation of crosscutting concerns. Let s take a look at how you can recognize these symptoms. Code tangling Code tangling is caused when a module is implemented that handles multiple concerns simultaneously. A developer often considers concerns such as business logic, performance, synchronization, logging, security, and so forth while implementing a module. This leads to the simultaneous presence of elements from

Figure 1.7 Code tangling caused by multiple simultaneous implementations of various concerns. The figure shows how one module manages a part of multiple concerns.

each concern s implementation and results in code tangling. Figure 1.7 illustrates code tangling in a module. In the code snippet for the SomeBusinessClass class in listing 1.1, the method SomeBusinessClass.someOperation1() contains code for authorization, contract enforcement, optimization, and logging, all tangled up with the core operation. Similarly, SomeBusinessClass itself contains operations for persistence management as well as a support structure for logging and cache management, which tangles them with the core state and behavior of the module. Code scattering Code scattering is caused when a single issue is implemented in multiple modules. Since crosscutting concerns, by definition, are spread over many modules, related implementations are also scattered over all those modules. For example, in a system using a database, performance concerns may affect all the modules accessing the database. We can classify the code scattering into two distinct categories: duplicated code blocks and complementary code blocks. The first kind is characterized by repeated code of a nearly identical nature. For example, resource pooling will typically involve adding nearly identical code to multiple modules to fetch a resource from a pool and return the resource back to the pool. Figure 1.8 illustrates the scattered duplicated code blocks.

Figure 1.8 Code scattering caused by the need to place nearly identical code blocks in multiple modules to implement a functionality. In this banking system, many modules in the system must embed the code to ensure that only authorized users access the services.

The second kind of code scattering happens when several modules implement complementary parts of the concern. For example, in a conventionally implemented access control system, you will perform authentication in one module, pass the authenticated user to modules that need authorization, and then those modules will perform the required authorization. All these pieces must be carved to fit together perfectly much like puzzle pieces to implement the functionality, as shown in figure 1.9. In figure 1.9, multiple modules include code for authentication logic and access checking; they must work together to correctly implement the authorization. For example, before you can check the credentials of a user (access control), you must have verified that user s authenticity (authentication).