Aspect-oriented programming: Difference between revisions

Revision as of 13:56, 19 April 2020

Revision as of 13:58, 19 April 2020

Line 162:

# 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 process 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.

Any solution that combines programs at runtime has to provide views that segregate them properly to maintain the programmer's segregated model. Java's bytecode support for multiple source files enables any debugger to step through a properly woven .class file in a source editor. However, some third-party decompilers cannot process woven code because they expect code produced by Javac rather than all supported bytecode forms (see also "[[#Criticism|§ Criticism]]", below).

[[Deploy-time]] weaving offers another approach.<ref>{{cite web |url=http://www.forum2.org/tal/AspectJ2EE.pdf |title=Archived copy |accessdate=2005-06-19 |url-status=dead |archiveurl=https://web.archive.org/web/20051008065854/http://www.forum2.org/tal/AspectJ2EE.pdf |archivedate=2005-10-08 }}</ref> This basically implies post-processing, but rather than patching the generated code, this weaving approach ''subclasses'' existing classes so that the modifications are introduced by method-overriding. The existing classes remain untouched, even at runtime, and all existing tools (debuggers, profilers, etc.) can be used during development. A similar approach has already proven itself in the implementation of many [[Java EE]] application servers, such as [[IBM]]'s [[WebSphere]].

Line 174:

Standard terminology used in Aspect-oriented programming may include:

;Cross-cutting concerns: {{main article|Cross-cutting concern}} Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Further concerns can be related to security such as [[Access control#Computer security|access control]] <ref name="dewin2002">B. De Win, B. Vanhaute and B. De Decker. "Security through aspect-oriented programming". In ''Advances in Network and Distributed Systems Security'' (2002).</ref> or [[Information flow (information theory)|information flow control]].<ref name="pasquier2014">T. Pasquier, J. Bacon and B. Shand. "FlowR: Aspect Oriented Programming for Information Flow Control in Ruby". In ''ACM Proceedings of the 13th international conference on Modularity (Aspect Oriented Software Development)'' (2014).</ref> Even though each class has a very different primary functionality, the code needed to perform the secondary functionality is often identical.

;Advice: {{main article|Advice (programming)}} This is the additional code that you want to apply to your existing model. In our example, this is the logging code that we want to apply whenever the thread enters or exits a method.

;Pointcut: {{main article|Pointcut}} This is the term given to the point of execution in the application at which cross-cutting concern needs to be applied. In our example, a pointcut is reached when the thread enters a method, and another pointcut is reached when the thread exits the method.