Section 12.4. CONCLUSION

12.4. CONCLUSION

In this chapter, we presented reflection and how it can be used to support AOP. We described the MetaclassTalk MOP and showed one possible approach to use it in order to implement isolated aspects and then weave them together.

An aspect can be implemented in isolation since its definition is a compound of a set of generic meta-object classes and a configuration script. Meta-object classes define aspect specific processing (e.g., synchronization), while the configuration script expresses when and where to perform this processing (i.e., it specifies join points). In fact, the configuration script allows you to create meta-objects, initialize them, and link them to base objects. Since the specification of the join point is provided by the configuration script, meta-object classes are generic. Thus, they can be reused in other applications, paving the way for aspect reuse.

In the previously described context, weaving is performed by evaluating aspect configuration scripts. As a result, each base object can be linked to many cooperating meta-objects. This relationship can be updated at runtime by adding or removing meta-objects. Thus, the use of reflection provides flexibility. Applications can be adapted or evolved by dynamically weaving and unweaving aspects.

It's worth recalling that the approach presented previously is only one possible way to support AOP. Many other approaches to represent and weave aspects can be developed using reflection. Particularly, different strategies for dealing with non-orthogonal aspect weaving can be studied. Reflection is not only a way to support AOP, but it is also an ideal test bed to evaluate solutions for AOP open issues.