What is AOP? Deng Hui
A core problem that has been in software development is how to better meet the Separation of Concerns principles proposed by Dijkstra. This principle expresses a most important feature of the code and development process, but unfortunately it is just a principle, which doesn't tell us how to meet this principle. A lot of explorations have been taken to meet the implementation techniques that meet this principle, and many achievements have been made. Among them, ASPECT-oriented Programming is a new technology in this area. The concept of AOP is originally proposed by researchers from the Xerox Parc Research Center, and its goal is to decompose the problem into a series of Functional Component and a series of aspects across multiple Functional Components by providing some methods and techniques. These Component and Aspect are achieved by the implementation of the system. It is basically in an academic research and test phase for a long time in AOP. However, in recent years, the situation has changed. Due to the continuous improvement of enterprise application complexity, new challenges have been put forward on software development technology. How to make the application developers only focus on the development of business logic itself, without entanglement of those necessary to implement business logic without entanglement, such as security, transactions, logs, etc. If there is a technology that is unrelated to these and specific business logic but is an indispensable function block that is indispensable for each application, and the business logic is clean, and it is possible to pass some simple configuration or "glue" code. When you need to "woven" to your application, you will not only greatly improve the development efficiency, but also reduce the complexity of the software, but also wellly improved in terms of code, modular, and testability. This is the problem to be solved by AOP. Below I will start from systematic analysis, design activities, introduce the AOP to the end, it solves what difficulties we face. What is AOP? When we have software development, the most ideal situation should be: Each demand concept element can have a direct, clear representation in the source code. If we can do this, it is possible to focus on the impact of changes, and this is exactly the team's efficient parallel development, the structure of the architecture smooth evolution and effectively reaching iteration. For example, in the access network software system developed by our project, the concept of PSTN user port directly corresponds to a design in the program: Pstnuser class. The concept of V5 link also corresponds directly to a design representation: LINK class. Let's consider such a requirement that due to the high reliability requirements of the telecommunications level, the system must provide the functionality of the active and standby. In order to be able to achieve the active preparation function, in addition to some of the requirements of hardware, we must also do this when a business object changes, we must synchronize the state to the standby machine when there is a change in the state of the business object. After switching, the system can also provide normal business functions. It can be seen that this is a single demand description, but such a simple single functional requirement is difficult to be mapped to a single design representation. In general, we will put on the logic of triggering synchronization on the status of the business object needs to be synchronized. This implementation approach departs from the demand and the target of one-one mapping, which is the opposite of this is a pair of mapped relationships between implementation. The demand elements that are captured in the design, generally likely to change with the development of software development, the evolution of the program. If you do a demand element and one map between our program, this implementation structure is very easy to modify and maintain. Conversely, if it is one to multi-mapping, it will be very difficult when modified or maintained, because there are many places in the implementation structure to be updated, and these updates must be guaranteed to be complete and consistent.
If you miss a place, or if you don't do it, you will cause some very subtle bugs, and these BUGs are likely to spend a lot of time. Now, let's take a look at this problem. We hope that each demand concept element can be clearly mapped to an implementation structure. We also want each implementation structure to be clearly mapped to a unique demand concept element. However, in the examples listed above, we see that the business object status synchronization This demand concept element is spread in the implementation, which means that multiple demand elements have to be handled in the implementation of the business object. For PSTNUser, it is now handling at least two demand concepts: 1. Implement the logic of the PSTN user port itself; 2. Synchronization of the business status when needed. This is a typical demand concept element and a multi-to-one mapping relationship between structures. The keen reader will definitely find this situation violates SRP (Single Responsibility Princi). This multi-to-one situation also brings a lot of problems. Because in a class, in addition to the need to implement itself, there is no other feature that has nothing to do with this demand concept, such as synchronous, transaction, security, and persistence. These and unrelated elements do not only make the class have multiple changes, but also cause great invasivity to this class, making this class extremely difficult to reuse, test. In general, we are more complicated in real software development, we basically can't encounter an ideal concept and one map of realization, but multi-to-many mappings. This is also caused such that software is so difficult to maintain, and it is difficult to understand, so complicated. Although the object-oriented method has achieved a small progress in solving this problem, it is still unable to make us clear and clean mapping relationships between the needs concept elements and the realization structure. And this is what aspect-oriented programming is trying to solve the problem. With AOP, we have taken a big step in achieving a map. Introducing a new construction element aspect in AOP, through which we can achieve a need concept element in OOP and one by one of the implementation of the structure, such as: The system service status synchronization requirements mentioned earlier. Keep in mind that what we are pursuing is a demand concept element and a map between the implementation structure. Whenever, no matter what reason, we will encounter trouble as long as it is from this goal. Structural Programming, Object-Based Programming, Object-Oriented Programming, Functional programming, Generic Programming and Aspect-Oriented Programming The programming paradigm is to help us reach this goal closer at some latitude. Case Studies In general, complete AOP development is required to develop environmental support, such as AspectJ, Spring or JBoss. For C languages, there is no need to have a practical test for the development environment that has been implemented by a practical test, and it is not necessary to say embedded systems. However, we can still achieve the effect of AOP through some common technologies. In this section, I will introduce two technologies that are commonly used through an example in the project. I also introduced as an example with the PSTNUser object state synchronization mentioned above. The code pieces of traditional implementation methods are as follows: Class Pstnsynagent {//... .Public: Static Void ASKFORSYNHOOKON (V5IID, L3ADDR); static void askforsynhookoff (V5IID, L3ADDR) //..
void PstnUser :: HookOn () {// do something corresponding to HookOn Event PstnSynAgent :: AskForSynHookOn (GetV5IID (), GetL3Addr ());....} void PstnUser :: HookOff () {// do something corresponding to HookOff Event.................................................................... Method. The Pstnuser object itself violates SRP, which is not only to complete the logic of PSTNUser itself, but also to complete the synchronous trigger logic. Below we will reach AOP to eliminate the above flavors by two conventional technical techniques. These two methods are: Decorator Mode and Policy-based Design. 1) When using Decorator mode, AOP is reached when using Decorator mode, is actually an additional duty of the synchronization logic as a PSTNUser object, placed in another separate Decorator object, thereby eliminating the above taste. Readers who are familiar with the Decorator model must have understood how to do it, and they will not be described here. The changed code is as follows: // Defines the interface class ipstnuser {//.. .Public: virtual void hookon () = 0; Virtual void hookoff () = 0;}; Class Pstnsyndecorator: public}; Public: PSTNSYNDECorator: user_ (user) {} void hookon () {user _-> hook (); pstnsynagent :: askFORSYNHOOKON (user _-> getv5iid (), user _-> getl3addr ());} void hookoff () {User _-> hookoff (); pstnsynagent :: askFORSYNHOKOFF (user _-> getv5iid (), user _-> getl3addr ());} //... .Private:} //... .Private: ipstnuser * user _;}; class pstnuser: pubic odstnuser { Public: void hookon () {// do something corresponding to hookOff () {// do sometying corresponding to hookoff Event....} //...}; // Create an object When you do this, IPSTNUSER * PSTNUSER = New PstNUser (IID, ADDR) // Create a normal PSTNUser object ipstnuser * synpstnuser = new PstnsyNDecorator (PSTNUser) / / increase synchronization function for normal PSTNUser objects.
In this way, the business object status synchronization requirement and the PSTNSYNDECORATOR class correspond to the PSTN user port, and the functional requirements of the PSTN user port correspond directly to the PSTNUser. 2) Using Policy-Based Design AOP in this method, in this way, it is actually combined with the business object status synchronization logic as a policy, combining this policy and business object logic itself, eliminating the above flavor . Policy-based Design technology is implemented by Template and MultiPle-Inheritance in C . For details on policy-based Design, see the "Modern C Design" book, which is no longer introduced. Code changes as follows: template
