The main modules of this book are the benefits of modular methods and models, OSGi simple use and other content, 3 of the majority:
The first part introduces the concept of modularity, why modularity, and some of the modularity to consider things, such as module granularity, dependency, reusability flexibility and so on.
The second part introduces some modes of modularization, adopts the format of GOF design pattern (pattern name, pattern expression, diagram, description, various realization, effect, sample, summary), looking at some chaos, but harvest a lot.
The third section 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 is deferred to Jave SE 9) because you can access any of the public methods in other module classes at any time, you want to enforce modularity, only allow access to published methods, and you can use the OSGi framework.
The modular concept and component-like, deployable, manageable, native reusable, composable, stateless software units provide an external interface to the introduction. In Java, the most appropriate unit for modularity is the jar file.
At the level of code we are focused too much, and skilled developers are now rarely arguing about the benefits of using patterns, and no longer recognize which patterns are appropriate for the current needs, because they instinctively use various design principles and patterns, from GOF design patterns to derived design principles, and now many principles have become almost instinctive, such as " The combination of precedence rather than inheritance "," toward abstraction rather than implementation oriented ".
But considering only the class-level design, no matter how beautiful the design is, the code expects no benefit. 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 classes that implement 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, many methods are based on the principle of "dependence on abstraction rather than on implementation".
1, the paradox, the smaller the size of the module more flexible, management is more complex, how to flexibility and management complexity of the choice between. Maximized reuse makes available complications, the smaller the granularity of the module reusability, the lower the availability, that is, the more inconvenient to use, how to trade-offs between reusability and usability. Although there is no absolute conclusion, there is a conclusion in the general direction.
2, stability, with a large number of dependent modules should be very stable, that is, there is little change, the impact of change is greater. The best way to ensure the stability of the module is to convert it to an abstract module. Modules with a lot of dependencies on other modules are unstable, easy to change, easy to use, but not easy to test (because there are too many dependencies on other modules), the best way to rely on abstract modules.
3, the module level must be graded, the module must be hierarchical, high-level dependence on low-grade, low-grade can not rely on high-level, low-grade can not have too much reliance, the lower the level of the module should be more stable, unstable modules should be put to a high level.
4, module reuse, class-level reuse can not cross-application (such as tool classes), and module-level reuse across the application.
at the beginning of software development, the requirements are constantly changing, and the granularity of the modules should be large, easy to manage and use. As the focus of identifying demand changes is identified, where reusable is found, larger modules should be split into smaller, more reusable, fine-grained modules. It is difficult to try to define smaller fine-grained modules in the early stages of software development, because it is only possible to guess where the reuse point is and usually 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. Software development should be based on the change Frequency building module, because the system is unstable, system stability, should be based on the reuse of building modules. In other words, it is difficult to create high cohesion modules in the early stages, and as the system stabilizes, the development team should reorganize the system to ensure that the modules are cohesive.
6, module dependence, high-level module one-way dependent low-level module is the best, the most bad is the cycle of dependence, here are several ways to eliminate dependency. when one-way dependencies, such as low-level modules rely on high-level modules, the workaround: Inverse Relationship: Stability Module A relies on the partial abstraction of B, relies on its own interface, B to implement this interface, to achieve B dependency a reversal.
Eliminate the Relationship: Abstract the module C,a relies on C (a using C), B relies on C (b implementation c), to A and b do not depend on the relationship.
Two modules have a cyclic dependency, which is usually a module that should be merged. If non-merger is to break the relationship, the solution is:
Move up: Moves the dependency Genesis up to the high-level module, creating a higher-level module, abstracting the lowest-level module dependencies, and achieving one-way dependencies.
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, through the reversal and elimination, but also to solve the cyclic dependence, according to the specific use of the scene to choose it.
7, the module should be lightweight, independent of the container and the operating environment, can be deployed using the best.
8, module management, if you do not plan to reuse a module, then the power of dependency management is maintainability, if you want to improve maintainability, it is necessary to focus on testability (the easier to test, the easier to maintain). It's best to start with as simple as possible and increase the module as the need arises, rather than creating complex modules based on predictions at the outset.
9, the default implementation, the module should have a default implementation, if there is no implementation, the module is actually just a specification. (for example, the default implementation is a way to plug-in development.) )
10, dependent on the abstraction must be guaranteed to obtain an instance of the implementation class, not new, commonly used methods have 3 classes, factory methods, dynamic creation (such as spring injection), Osgiμservice.
11. If all classes that are dependent on the abstract are in one module, place them in the same module as the abstract body. If all classes that rely on the abstract body are in multiple modules, place the abstract body in a separate module.
Finally, why use OGSI to force modularity, "elegant concept design can quickly become a mess in the process of implementation, no developer can understand how the original high-level vision will be presented in the code." Although you know exactly what the desired module relationship is, the unwanted dependencies will still come into your application. "The real situation is true, whatever the reason, the end result is the same, that is, our code is getting worse, the module relationship is confusing, the code can be reconstructed 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 require modification of the build script, it is important to be cautious about defining new dependencies for developers. Hierarchical construction makes it much more to introduce new dependencies. "
At the beginning of the work, many features of the development process if you have to configure a number of configuration files, then feel very troublesome, has not found a compelling reason, read the book finally found:
1, configuration complex usually represents a high degree of flexibility, the more flexible use of the more trouble, the more flexible more complex, a lot of things like this, there is no perfect, only the most suitable for the current balance point.
2, complex configuration, so that developers more cautious, if there is no such a complex configuration, developers will casually write, resulting in a system extremely bad mess.
3, complex configuration, concentrated in one or a kind of place, also convenient to review carding.
Finally, the modular design of this book I have a lot of ideas, is not particularly popular, I hope the future will become very popular, future OSGi will also bring the ecosystem (Eclipse is the successful OSGi based ecosystem).
(reading notes) Java Application Architecture Design-Modular mode and OSGi
