AOP@WORK:AOP and Meta data: Perfect Match, part 2nd-multidimensional interface with meta data

Introduction: In this second installment of a two-part series on combining metadata and AOP, the author and AOP practitioner Ramnivas Laddad will recommend a new way to treat metadata as a signature in multidimensional focus space. He will also describe a set of guidelines for effectively combining metadata with AOP, and discuss how metadata annotations will affect the application of aspect-oriented programming.

In the first part of this article, I introduced the new Java metadata features and explained how and where metadata annotations can be most effective at enhancing the AOP connection point model. I also summarize three of the most important AOP systems that have support for metadata, three of which are: Aspectwerkz, AspectJ, and JBoss AOP. In the first section, the impact of metadata on the modularity of AOP systems is also described, and finally an example is rebuilt to show how to incrementally add metadata annotations to an AOP system.

In the second part of this article, I'll introduce a new approach that sees metadata as a way to the multidimensional signature space. This method has the practical purpose of decomposing element signatures and is useful in general for designing annotation types, even for developers who are not engaged in AOP. In the second part of this article, I will still focus on the most efficient use of metadata methods in object-oriented programming. Among them, I will demonstrate a use of AOP to effectively reduce the modular loss associated with metadata annotations. At the end of this article, I'll provide a set of guidelines for determining when and how best to leverage metadata. I will also consider the impact of adding metadata on the adoption of AOP.

The tyranny of the leading signature

The signature of a program element, such as a type, method, or field consisting of several components, including element names, access specifications, base types, method parameters, exception rules, and so on. Not every program element uses all the components, but in any case the name of the program element is the most valuable thing, especially when it is exposed, because it notifies its users of the role of that element.

If you do not use Meta data programming, you can use only one name per program element. In this case, it is common practice to name program elements as their primary or primary function. For example, consider the signature of the credit method below:

public void credit(float amount);

This method name reflects only one attribute of the method: The business logic that carries out the credit business. All other features of the element are lost. Although this signature can tell the customer who uses this method of the main functionality of the element, it cannot notify other customers-those customers who implement crosscutting concerns, such as security and incident management customers. This is the tyranny of the dominant signature, which is caused by using only one name to represent the constraints of the element.

Similar situations are often discussed in the AOP research literature: The tyranny of the primary decomposition (decomposition), where the main focus (usually the business logic) governs the design of the class, especially the inheritance hierarchy (inheritance hierarchy).

Signature Tangle

One way to ensure that the signature of an element matches its crosscutting functionality is to modify the name of the signature so that it reflects all features. For example, a credit business that needs to be run and certified in a transaction can have the following signature:

public void transactional_authorized_credit(float amount);

When you see a name like the one above, it does allow you to think about the crosscutting transaction and authentication requirements of the method, but it makes the code so bad that only a few developers will use it. In fact, this name is only seen in special circumstances, such as using a special naming convention to identify the method as internal consumption.

With the development of the system, the above method will bring a serious problem. If the crosscutting characteristics of the program element change, then its name and all its references need to be changed accordingly. For example, if in the above example, the development of the system makes the credit business no longer requires authentication, the method name needs to be changed to Transactional_credit (), and all calls to the method are changed accordingly.

Another problem with this approach is that combining the names of elements from multiple concerns increases the caller's identification burden. For example, the business caller of the above method is not interested in other features of the method, but is still affected by other concerns.

If you are familiar with AOP, you already know that code entanglements-mixing multiple focus codes into one module-can lead to code that is difficult to understand and difficult to maintain. The signature tangle is similar to this. As in the above example, when the name of a program element reflects its role in multiple concerns, we call it a tangled signature.