(Notes) Java Application Architecture Design-Modular mode and OSGi

This book is mainly about the advantages of modular mode, modular approach and mode, OSGi simple use and other content. 3 of the most:
The first part introduces the concept of modularization. Why modularity, and some modularity to consider, such as module granularity, dependencies, reusability flexibility, etc.

The second part introduces some modes of modularization. Adopt the format of GOF design pattern (pattern name, pattern expression, diagram, descriptive narration, various realization, effect, example, summary), look at some chaos, but harvest a lot.
The third part describes how OGSI is used in conjunction with Java. And how to modularize existing systems. There is no direct modularity in Java (the Java SE modularity feature Jigsaw has been postponed to Jave SE 9), because you are able to access the random public method in other module classes at any time, want to be mandatory modularity, just agree to visit the published method, be able to use the OSGi framework.

The modular concept and component-like, deployable, manageable, native reusable, composable, stateless software units provide a simple interface to the outside. In Java, the most appropriate unit for modularity is the jar file.

watermark/2/text/ahr0cdovl2jsb2cuy3nkbi5uzxqvehvlcglhb2hhbjiwmdy=/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma== /dissolve/70/gravity/center ">

At the level of code we are focused too much, and skilled developers are now very little arguing about the merits of using patterns, and no longer recognize which patterns are appropriate for the current needs. Since all design principles and patterns can be used instinctively. From the GOF design pattern to the derived design principles, many principles have almost become instinctive. such as "precedence combination rather than inheritance", "towards abstraction instead of implementation oriented".

But just consider class-level design, so no matter how beautiful the design is, no code is expected to yield. Because existing design principles and object-oriented development patterns do not help manage the complexities of large software systems, they solve different problems.

The goal of the architecture is to minimize the impact and cost of change. Modularity helps us achieve this by bridging the gap between high-level architecture components and underlying code.



The general principle:
1. Interfaces are closer to classes that use them. And away from the class that implements them.
2. Exceptions should be close to the class or interface in which they are thrown, rather than the module that is approaching the catch exception

Some of the modular patterns and methods, the general principles of thought and the principle of class design are similar, very many methods are based on the principle of "dependence on abstraction rather than the implementation of dependency."

1, Paradox, the smaller the size of the module more flexible. The more complex it is to manage, the tradeoff between flexibility and management complexity. Maximizing reuse makes available complications. The smaller the granularity, the higher the reuse of the module. The lower the availability, the less convenient it is. How to trade-offs between reusability and usability. Although there is no absolute conclusion, generosity has a conclusion.

2, stability, with a large number of dependent modules should be very stable, that is, very little change. The impact of change is even greater. The best way to ensure the stability of the module is to convert it to an abstract module. A large number of modules that rely on other modules are unstable, very easy to change, ease of use, but not easily tested (due to the dependence of other modules too much). The best way should be to rely on abstract modules.

3, the module level must be graded. Modules must be hierarchical and high-level dependent on low grade. Low levels cannot depend on high levels. Low level can not have too many dependencies, the lower the level of the module should be more stable, unstable modules should be put to high level.

4, module reuse, class-level reuse can not cross-application (for example, tool Class), and module-level reuse can be applied across.

In the early stages of software development, demand is constantly changing. The granularity of the module should be large. Easy to manage and use. With the focus on identifying changes in demand. Find a place to reuse. Larger modules should be split into smaller, easier-to-reuse fine-grained modules. It is very difficult to try to define a smaller fine-grained module in the early stages of software development, because it is only possible to predict where the reuse point is and generally fail.

5, module cohesion: High cohesion module easy to understand, maintain and reuse. The factors that affect the cohesion of the module are 2 points, one is the frequency of the class change, and the other is the reusability of the class. The software development should be based on the change Frequency building module, because the system is unstable and the system is stable, it should be based on reuse building module. In other words, the software is very difficult to create high cohesion modules, as the system is stable, the development team should organize the system again to ensure that the modules are cohesive.

6, module dependence. High-level modules are one-way dependent on low-grade modules that are best, and the worst is the cyclic dependency, which provides several ways to eliminate dependencies.

one-way dependency, for example, low-level modules rely on high-level modules, the solution: Inverse Relationship: Stable module A relies on part of the abstract interface of B. Rely on their own interfaces. B to implement this interface, to achieve B-dependent inversion of a.

Eliminate relationship: Abstract out module C. A relies on C (a uses C). b relies on C (b implementation C) to achieve A and B are not dependent on the relationship.

Two modules have a cyclic dependency, which is usually a module. should be merged. Assuming that the non-merger is going to break this relationship, the solution is:
Move up: Move the dependency Genesis up to the high-level module and create a higher-level module. Abstract the lowest-level module dependencies to achieve one-way dependency.
Move Down: Move the dependency cause down to the high-level module, creating a lower-level module instead of moving up.
callback: Define an abstract body, inject it into the module, achieve one-way dependency or even eliminate the dependency of the possible. In fact by reversal and elimination. can also solve the cyclic dependence. Choose from a detailed usage scenario.

7, the module should be lightweight. Independent of container and execution environment, can be deployed using best.

8, module management. Assuming that a module is not intended to be reused, the power to rely on management is maintainability, and if you want to improve maintainability, focus on testing (the easier it is, the easier it will be to maintain).

It's best to start with as simple as possible and increase the module as the need arises, rather than creating a complex module based on a prediction at the beginning.

9, the default implementation. The module should have a default implementation, assuming that no matter what implementation, the module is actually just a specification.

(for example, the default implementation is a way to plug-in development.) )

10, dependent abstraction must be guaranteed to get an instance of the implementation class, not new, there are 3 types of frequent usage, factory methods, dynamic creation (such as spring injection), Osgiμservice.

11, assuming that all classes that rely on abstractions are in one module, then place these classes and abstractions in the same module. Assume that all classes that rely on the abstract body are in multiple modules. Then put the abstract body into a separate module.

Finally, why use OGSI to force modularity. "Elegant concept design can become a mess very quickly in the process of implementation, and no developer can understand how the original high-level vision will be present in the code. Although you are well aware of what the expected module relationship is. But unwanted dependencies will still come into your application. "The truth is true, for any reason, and finally the result is the same." Is that our code is getting worse, the module relationship is confusing, the code can be refactored periodically, but the cost of the module refactoring is relatively large, OGSI has a way to force the solution, "hierarchical construction will force you to think about module dependencies ... Because any new dependencies need to change the build script. So for developers, it's necessary to be cautious about defining new dependencies.

Hierarchical builds allow for the introduction of new dependencies to do a lot of other things. "

Span style= "font-size:18px" > Just when you were working, Very versatile in the development process assuming that several configuration files must be configured before use, it was difficult to find a compelling reason to read the book and finally found out:

Span style= "font-size:18px" > 1, configuration complexity usually represents a high degree of flexibility. The more flexible the more cumbersome, the more flexible the more complex, very much so, there is no perfect, just the most suitable for the current balance point.
2, Complex configuration that allows developers to be more cautious, assuming there are no such complex configurations. Developers will write randomly. Finally caused the system extremely bad mess.
3, Complex configuration, concentrated in one place or another. Also easy to review carding.

Finally, the modular design of the book has made me a lot, not yet particularly popular, I hope the future will become very popular, future OSGi will also bring the ecosystem (Eclipse success is based on the OSGi ecosystem).

Copyright notice: This article blog original article. Blogs, without consent, may not be reproduced.

(Notes) Java Application Architecture Design-Modular mode and OSGi