Editing Aspect-oriented programming (section)

==Implementation==
AOP programs can affect other programs in two different ways, depending on the underlying languages and environments:

# a combined program is produced, valid in the original language and indistinguishable from an ordinary program to the ultimate interpreter
# 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 type of [[program transformation]] known as ''weaving''. 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 the method of combination 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 must 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|§&nbsp;Criticism]], below).

[[Deploy-time]] weaving offers another approach.<ref>{{cite web |url=http://www.forum2.org/tal/AspectJ2EE.pdf |title=Archived copy |access-date=2005-06-19 |url-status=dead |archive-url=https://web.archive.org/web/20051008065854/http://www.forum2.org/tal/AspectJ2EE.pdf |archive-date=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, such as debuggers and profilers, 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]].

===Terminology===

Standard terminology used in Aspect-oriented programming may include:

;Cross-cutting concerns: {{main article|Cross-cutting concern}} Even though most classes in an object-oriented 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 refers 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.
;
;Aspect: {{main article|Aspect (computer science)}} The combination of the pointcut and the advice is termed an aspect. In the example above, we add a logging aspect to our application by defining a pointcut and giving the correct advice.