Learn about AOP
Object-oriented technology is well solved the problem of role in the software system. With object-oriented analysis, design, and implementation techniques, developers can convert "noun" in the field into an object in a software system, which is naturally completed from issues to software. However, some demands in the problem are not described in such a "noun". One of my friends has encountered such a problem: I need to log logging to some methods in the system, which requires a record method to spread in more than 40 classes. What should I do if I face this need? The most direct way is to create a class (or interface), put the log's function in it and let the classes that need log functions inherit this setting (or interface). If this demand is presented later. If you need to modify, you will be scattered in more than 40 files (if it is C 10, this number may also double). Such large modifications will undoubtedly increase the chance of error and increase the difficulty of system maintenance. It is recognized that traditional procedures often exhibit some behaviors that cannot naturally fit a single program module or several closely related program modules, such as logging, which are sensitive to context, performance optimization, and design patterns, we will "CrosscuttingConcern" is called "CrosscuttingConcern" because it spans typical duties in a given programming model. If you have used the code for the nuclear cut concern, you will know the question of the lack of module. Because the implementation of cross-cut behavior is dispersed, the developers find this behavior difficult to logic thinking, implementation, and changes. Therefore, aspect-oriented programming, AOP is delivered. AOP provides developers with a mechanism to describe cross-cutting points, and automatically use cross-cutting points into an object-oriented software system to achieve modularization of cross-cutting points. By dividing the Aspect code, the cross cuts become easy to handle. Developers can change, insert or remove the system's Aspect, and even reuse the ASPECT of the system. More importantly, AOP may have a fundamental impact on the process of software development. We can imagine that the OOP is only used to represent the generalization- Specialization relationship between the object (by inheritance), and the command between the objects is completely used by AOP. In this way, many design modes (such as Decorator, Role Object, etc.) will no longer be necessary. A programming idea is really excellent, only from the implementation of the language to see. Xerox Parc has developed the first AOP development environment - the planpectj, which provides a complete set of grammar, which can clearly describe cross-cutting points and woven it into Java. Source code. The woven code is still a standard Java code, so AsPectj does not affect Java's granting capabilities. In addition, AspectJ provides a separate IDE and can be embedded in Java development environments such as JBuilder, Forte, seamlessly providing AOP capabilities. About AspectJ, readers can find more information at http://www.aspectj.org.
However, the current AOP is still in a fairly imperfect stage: it can only be applied to few languages, and must master the source code to woven. However, scientists represented by RUP's parent Ivar Jacobson are still advocated to AOP: He believes that AOP will eventually change the entire software development, and more perfectly realize the development of "use case drivers". Using AOP Separation Software Focus on point a payment point (Concern) is a specific purpose, an area we are interested in. From a technical perspective, a typical software system contains some core focus points and system levels. For example, a core concern of a credit card processing system is to lend / deposit processing, and the system-level focus point is log, transaction integrity, authorization, security, and performance, many attention points - we call It crossscutting converns - will appear in multiple modules, using existing programming methods, cross-cutting points will cross multiple modules, and the result is to make the system difficult to design, understand, implement, and evolve. The AOP can better separate the system concerns than the above method to provide modular cross-cutting points. In this article, I will first explain the problems caused by cross-cutting points in the software system, and then I will introduce how AOP solves the problem of cross-cutting points. The evolution of the software programming method is programmed by developers using simple machine-level code in the early stages of computer science. Unfortunately, programmers have taken more time to consider a particular machine's instruction set rather than the problem that needs to be solved in his hand. Slowly, we turn to use high-level languages that allow for some abstraction to the underlying machine. Then it is structured language, we can break the problem into some necessary processes to complete the task. However, with the increase of complexity, we need more suitable techniques. Object-oriented programming method (OOP) allows us to see the system as a group of people working with each other. Class allows us to hide the implementation details. Multi-state provides public behavior and interfaces for related concepts, and allows specific components to change specific behaviors without accessing the basic implementation. The programming method and language determines our way to communicate with your computer. Each new methodology proposes a new method of decomposing: machine code, pseudo code, process and class. Each new methodology makes the mapping from the system requirements to programming concepts more natural. The development of programming methodology allows us to build a more complex system. This place is in turn, and we can establish a more complex system to add these techniques to allow us to deal with this complexity. Most software items are now selecting OOP programming. Indeed, OOP has demonstrated its ability to handle general behavior, but we will see (maybe you have already felt): OOP does not handle cross multiple - often not related - module behavior. In contrast, AOP fills this blank, which is likely to be a milestone for programming methodology. Watching the system as a batch of concerns We can regard a complex system as a combination of multiple attention points. A typical system may include a few aspects of interest, such as business logic, performance, data storage, log, scheduling information, authorization, security, thread, error check, etc., there is also a concern in the development process, such as easy to understand , Easy to maintain, easy to track, easy to expand, and Figure 1 demonstrates a group of attention to a group of attention to different modules to form a system. Developers build a system to meet multiple needs, we can categorize these requirements as core modular needs and system group needs. Many system-level demand generally is independent of each other, but they generally cross a number of core modules. For example, a typical enterprise application contains many cross-cut points, such as validation, logs, resource, system management, performance and storage management, etc., each payment point involves several subsystems, such as storage management attention Click to affect all stateful business objects.
Let's look at a simple example, consider an implementation framework that encapsulates business logic: public class homebusinessclass extendsotherbusinessClass {// core data member / / other data member: log stream, guarantee data integrity flag, etc. // Method of Overloaded Base Class Public Void PerformsomeOperation (Operationinformation Info) // Security Verification // Check that the incoming data meets the protocol // Locking object Is the food store when accessing the data integrity / / check the cache is The latest information // Record operation start execution time // Execute the core operation // Record operation Complete time // to unlock the object} // Some similar operations public void save (PersitanceStorage PS) {} public void save (PersitanceStorage PS) {}} In the above code, we noticed three questions: First, other data members are not the core focus of this class; the second PerformSomeOperation () implementation has made a lot of core operations, it is to handle logs, verification, Thread safety, protocol verification, and cache management, some peripheral operations, and these peripheral operations are also applicable to other classes; third, SAVE () and LOAD () permanent persistence constitutes the core of this class is unclear . The problem of cross-cutting points, although cross-cutting points will span multiple modules, but current technologies tend to use one-dimensional methodology to handle this demand, and to force the implementation of the corresponding demand in a single-dimensional space. This one-dimensional space is the core module level implementation. The implementation of other needs is embedded in this dominant space. In other words, the demand space is an n-dimensional space, and the space is a one-dimensional space that causes a bad demand to the implementation. It is not good to use the current methodology to achieve cross-cutting points. It will bring some problems, we can roughly divide these problems into two categories. 1. Code confusion: The module in the software system may take care of several aspects. For example, developers often consider issues such as business logic, performance, synchronization, logs, and security, and take into account the needs of all aspects, resulting in the implementation elements of the corresponding attention, causing code confusion. 2. Code Dispersion: Since the cross-cutting point is involved in multiple modules. Related implementations are also over these modules. For example, in a system that uses the database, performance issues affect all modules that access the database. This causes the code to disperse at all areas. Results The chaos and dispersed code will affect the design and development of the system from a number of aspects: the readability is poor: simultaneous implementation of the implementation of different attention points, making the corresponding relationship between the focus and its implementation are not obvious. Low output: Simultaneous implementation of several attention points to move the attention of developers to peripheral attention, resulting in a decrease in production efficiency. Low code reuse: Since a module implements multiple attention points, other systems that require similar functions cannot be used immediately. Further reduces production efficiency. The code quality is poor: the chaotic code covers the problem hidden in the code. Moreover, due to the simultaneous processing of multiple attention points. It should be paid to pay attention to the attention of attention. It is difficult to expand: narrow perspectives and limited resources always produce only the design of current concerns. New demand leads to new implementation. Since the implementation is not modular, it is to involve multiple modules. In order to modify the subsystem in order to make data, it is also quite a test to ensure that these modifications will not bring bugs.
Current Solution Since most systems include cross-cutting points, nature has formed some technologies to modular cross-cut points, including: mixing, design patterns, and solutions for specific problem domains. Using mixed class, you can postpone the ultimate implementation of your attention. The basic class contains an instance of mixing classes, allowing other parts of the system to set this instance. For example, the class that implements business logic contains a mixed Logger, which can set this Logger to get the appropriate log type, such as the Logger may be set to use the file system or a message middleware. In this manner, although the specific implementation of the log is delayed, the basic class must also call the log operation and control log information in all written logs. Behavioral design patterns, such as Visitor and Template Method mode, also allow you to postpone specific implementation. But just like mixing, the control - calling Visitor or Template Method logic - still left the basic class. Solution to specific problem domains, such as frameworks and application servers, allowing developers to handle certain cross-cutting points in a more modular manner. For example, the E J b (Enterprise Javabean architecture) can handle the perspective points such as the persistent, system management, performance, and container-management persistence. B E a N and the database mapping, but in most cases, developers still have to understand the storage structure. In this way, you use an XML-based mapping relationship descriptor to achieve cross-cutting points related to data persistence. Solution to specific issues provides a special mechanism to solve specific problems. Its disadvantage is that the developers must re-learn for each such solutions, and because this approach is related to a specific problem domain, which belongs to a specific The cross cuts outside the problem require special treatment. The design of the designer's two difficulties, not only considers the current needs, but also considers the need to be able to avoid patch everywhere. This will have a problem presence in the future. If you leak over the need for cross-cutting points in the future, you will need to modify or even re-implement many parts of the system; from another perspective It is too concerned that it is not necessarily required to cause excessively designed, difficult to understand, bloated systems. Therefore, the system designer is in such a two difficult situation: how to design calculate too much design? It should be reasonable to design is not too much? For example, is the designer should include the log mechanism that is not needed in the system? If so, where is the point you should write a log? The log should record the similar examples of information, and there is a problem with performance, and we rarely predict the bottleneck. Common methods are to establish a system, profile, and then refurbish the system to improve performance, which may modify the system in accordance with PROFILING. In addition, with time, due to changes in the use, new bottlenecks may also be generated. The task of the library designer is more difficult because he is hard to enlighten the way of use of the class library. All in all, the designer is hard to take into account all the attention points that the system may need to process. Even under the premise of knowing the demand, some details needed to establish a system may not be obtained, and the overall design faces two difficulties in designing insufficient / over-design. The AOP foundation to discuss the current discussion is good for modular cross-cutting points. Researchers have tried a variety of ways to achieve this task, which has a common topic: separation attention. A o P is one of these methods, and its purpose is to clearly separate attention points to solve the problems mentioned above.
AOP, from its essential, allow you to achieve independent attention in a loosely coupled manner, then combine these implementations to establish the final system, use the system it builds to use loose coupling, modular implementation The transverse focus is set, and the system established with the OOP is achieved by the general concern of a loosely coupled modular implementation. In AOP, these modular units are called "aspect", and in OOP, these general interest points are called classes. AOP includes three clear development procedures: aspect decomposition: decomposition needs to have a cross-cut concern. In this step, you separate the core module-level focus and system-level cross-cutting points, you can decompose three attention points for the credit card mentioned earlier: Credit card processing, logs and verification. Confusion point implementation: Independent implementation of these concerns, also use the above credit card example, you want to implement the credit card processing unit, the log unit, and the verification unit. SCIENTIARATION: In this step, aspect integrators use a module unit - one side to specify the reorganization rule, the restructuring process - a weaving or integrating - uses this information. Build the final system, which also takes the example of your credit card. You can specify (the language provided by a AOP) requires a record, and each operation must pass before the business logic is involved. . The most important difference between AOP and OOP is to handle cross-cutting points. Each of the attention points in AOP does not know if other attention points will "pay attention" it. If the credit card processing module does not know other attention point implementation is making logs and verification operations for it. It shows a powerful development model that is converted from OOP. Note: An AOP implementation can use other programming models as its basis, so that it is unpacked to retain its basic model. For example, AOP can select OOP as its basic model, thereby taking OOP to handle the benefits of a focus. With such an implementation, independent general concerns can use OOP technology, which is like the process-based language is the basis of many OOP languages. AOP language profiles are like other programming models, and the implementation of AOP consists of two parts: language specification and implementation. Language specification describes the basic unit and grammar of the language; language implementation verifies the correctness of the code according to the language specification, and converts the code into the form of the target machine. This section, I explain the AOP component. AOP language specification From an abstract angle in view of the AOP language to explain the following two aspects: Implementation: Map each requirement to code, then the compiler translates it into an executable code. Since the implementation of the focus occurs in the form of a designated process, you can use traditional languages such as C, C , Java, etc. Weaving rules specification: How to combine independent achievements to form the final system? In order to establish a language to specify a different implementation unit to form a final system rule. This specified language of the woven rule can be an extension of the language, or a completely different language. AOP language Implementation AOP compiler to perform two steps: 1. Assembly points 2. Assembly results are converted to executable code. AOP implementation can be used in a variety of ways, including source code to source conversion, which prestrates the source code of each aspect, generates the woven source code, and then hand it to the compiler of the foundation language, generates Final executable code. For example, in this way, a Java-based AOP implementation can first transform different aspects into Java source code, and then let the Java compiler transform it into one by section code. It is also possible to do woven in the bytecode level; after all, the bytecode itself is also a source code. In addition, the underlying execution system - a java virtual machine - one or the support AOP.
