Aspect-oriented programming: Difference between revisions

Revision as of 20:57, 11 December 2020

Revision as of 00:48, 15 December 2020

Line 166:

# the ultimate interpreter or environment is updated to understand and implement AOP features.

The difficulty of changing environments means most implementations produce compatible combination programs through a processtype of [[program transformation]] known as ''weaving'' – a special case of [[program transformation]]. An [[aspect weaver]] reads the aspect-oriented code and generates appropriate object-oriented code with the aspects integrated. The same AOP language can be implemented through a variety of weaving methods, so the semantics of a language should never be understood in terms of the weaving implementation. Only the speed of an implementation and its ease of deployment are affected by which method of combination is used.

Systems can implement source-level weaving using preprocessors (as C++ was implemented originally in [[CFront]]) that require access to program source files. However, Java's well-defined binary form enables bytecode weavers to work with any Java program in .class-file form. Bytecode weavers can be deployed during the build process or, if the weave model is per-class, during class loading. [[AspectJ]] started with source-level weaving in 2001, delivered a per-class bytecode weaver in 2002, and offered advanced load-time support after the integration of [[AspectWerkz]] in 2005.