Aspect-oriented programming

In computing, aspect-oriented programming (AOP) is a programming paradigm that aims to increase modularity by allowing the separation of cross-cutting concerns. It does so by adding behavior to existing code (an advice) without modifying the code itself, instead separately specifying which code is modified via a "pointcut" specification, such as "log all function calls when the function's name begins with 'set'". This allows behaviors that are not central to the business logic (such as logging) to be added to a program without cluttering the code core to the functionality.

AOP includes programming methods and tools that support the modularization of concerns at the level of the source code, while aspect-oriented software development refers to a whole engineering discipline.

Aspect-oriented programming entails breaking down program logic into distinct parts (so-called concerns, cohesive areas of functionality). Nearly all programming paradigms support some level of grouping and encapsulation of concerns into separate, independent entities by providing abstractions (e.g., functions, procedures, modules, classes, methods) that can be used for implementing, abstracting and composing these concerns. Some concerns "cut across" multiple abstractions in a program, and defy these forms of implementation. These concerns are called cross-cutting concerns or horizontal concerns.

Logging exemplifies a crosscutting concern because a logging strategy necessarily affects every logged part of the system. Logging thereby crosscuts all logged classes and methods.

All AOP implementations have some crosscutting expressions that encapsulate each concern in one place. The difference between implementations lies in the power, safety, and usability of the constructs provided. For example, interceptors that specify the methods to express a limited form of crosscutting, without much support for type-safety or debugging. AspectJ has a number of such expressions and encapsulates them in a special class, an aspect. For example, an aspect can alter the behavior of the base code (the non-aspect part of a program) by applying advice (additional behavior) at various join points (points in a program) specified in a quantification or query called a pointcut (that detects whether a given join point matches). An aspect can also make binary-compatible structural changes to other classes, like adding members or parents.

History

AOP has several direct antecedents A1 and A2:^[1] reflection and metaobject protocols, subject-oriented programming, Composition Filters and Adaptive Programming.^[2]

Gregor Kiczales and colleagues at Xerox PARC developed the explicit concept of AOP, and followed this with the AspectJ AOP extension to Java. IBM's research team pursued a tool approach over a language design approach and in 2001 proposed Hyper/J and the Concern Manipulation Environment, which have not seen wide usage.

The examples in this article use AspectJ.

The Microsoft Transaction Server is considered to be the first major application of AOP followed by Enterprise JavaBeans.^[3][4]

Motivation and basic concepts

Typically, an aspect is scattered or tangled as code, making it harder to understand and maintain. It is scattered by virtue of the function (such as logging) being spread over a number of unrelated functions that might use its function, possibly in entirely unrelated systems, different source languages, etc. That means to change logging can require modifying all affected modules. Aspects become tangled not only with the mainline function of the systems in which they are expressed but also with each other. That means changing one concern entails understanding all the tangled concerns or having some means by which the effect of changes can be inferred.

For example, consider a banking application with a conceptually very simple method for transferring an amount from one account to another:^[5]

void transfer(Account fromAcc, Account toAcc, int amount) throws Exception { if (fromAcc.getBalance() < amount) throw new InsufficientFundsException(); fromAcc.withdraw(amount); toAcc.deposit(amount); } 

However, this transfer method overlooks certain considerations that a deployed application would require: it lacks security checks to verify that the current user has the authorization to perform this operation; a database transaction should encapsulate the operation in order to prevent accidental data loss; for diagnostics, the operation should be logged to the system log, etc.

A version with all those new concerns, for the sake of example, could look somewhat like this:

void transfer(Account fromAcc, Account toAcc, int amount, User user, Logger logger, Database database) throws Exception { logger.info("Transferring money..."); if (!isUserAuthorised(user, fromAcc)) { logger.info("User has no permission."); throw new UnauthorisedUserException(); } if (fromAcc.getBalance() < amount) { logger.info("Insufficient funds."); throw new InsufficientFundsException(); } fromAcc.withdraw(amount); toAcc.deposit(amount); database.commitChanges(); // Atomic operation. logger.info("Transaction successful."); } 

In this example, other interests have become tangled with the basic functionality (sometimes called the business logic concern). Transactions, security, and logging all exemplify cross-cutting concerns.

Now consider what happens if we suddenly need to change (for example) the security considerations for the application. In the program's current version, security-related operations appear scattered across numerous methods, and such a change would require a major effort.

AOP attempts to solve this problem by allowing the programmer to express cross-cutting concerns in stand-alone modules called aspects. Aspects can contain advice (code joined to specified points in the program) and inter-type declarations (structural members added to other classes). For example, a security module can include advice that performs a security check before accessing a bank account. The pointcut defines the times (join points) when one can access a bank account, and the code in the advice body defines how the security check is implemented. That way, both the check and the places can be maintained in one place. Further, a good pointcut can anticipate later program changes, so if another developer creates a new method to access the bank account, the advice will apply to the new method when it executes.

So for the example above implementing logging in an aspect:

aspect Logger { void Bank.transfer(Account fromAcc, Account toAcc, int amount, User user, Logger logger) { logger.info("Transferring money..."); } void Bank.getMoneyBack(User user, int transactionId, Logger logger) { logger.info("User requested money back."); } // Other crosscutting code. } 

One can think of AOP as a debugging tool or as a user-level tool. Advice should be reserved for the cases where you cannot get the function changed (user level)^[6] or do not want to change the function in production code (debugging).

Join point models

The advice-related component of an aspect-oriented language defines a join point model (JPM). A JPM defines three things:

1. When the advice can run. These are called join points because they are points in a running program where additional behavior can be usefully joined. A join point needs to be addressable and understandable by an ordinary programmer to be useful. It should also be stable across inconsequential program changes in order for an aspect to be stable across such changes. Many AOP implementations support method executions and field references as join points.
2. A way to specify (or quantify) join points, called pointcuts. Pointcuts determine whether a given join point matches. Most useful pointcut languages use a syntax like the base language (for example, AspectJ uses Java signatures) and allow reuse through naming and combination.
3. A means of specifying code to run at a join point. AspectJ calls this advice, and can run it before, after, and around join points. Some implementations also support things like defining a method in an aspect on another class.

Join-point models can be compared based on the join points exposed, how join points are specified, the operations permitted at the join points, and the structural enhancements that can be expressed.

AspectJ's join-point model

Main article: AspectJ

• The join points in AspectJ include method or constructor call or execution, the initialization of a class or object, field read and write access, exception handlers, etc. They do not include loops, super calls, throws clauses, multiple statements, etc.
• Pointcuts are specified by combinations of primitive pointcut designators (PCDs).

  "Kinded" PCDs match a particular kind of join point (e.g., method execution) and tend to take as input a Java-like signature. One such pointcut looks like this:

   execution(* set*(*)) 

  This pointcut matches a method-execution join point, if the method name starts with "set" and there is exactly one argument of any type.

  "Dynamic" PCDs check runtime types and bind variables. For example,

   this(Point) 

  This pointcut matches when the currently executing object is an instance of class Point. Note that the unqualified name of a class can be used via Java's normal type lookup.

  "Scope" PCDs limit the lexical scope of the join point. For example:

   within(com.company.*) 

  This pointcut matches any join point in any type in the com.company package. The * is one form of the wildcards that can be used to match many things with one signature.

  Pointcuts can be composed and named for reuse. For example:

   pointcut set() : execution(* set*(*) ) && this(Point) && within(com.company.*); 

  This pointcut matches a method-execution join point, if the method name starts with "set" and this is an instance of type Point in the com.company package. It can be referred to using the name "set()".
• Advice specifies to run at (before, after, or around) a join point (specified with a pointcut) certain code (specified like code in a method). The AOP runtime invokes Advice automatically when the pointcut matches the join point. For example:

   after() : set() { Display.update(); } 

  This effectively specifies: "if the set() pointcut matches the join point, run the code Display.update() after the join point completes."

Other potential join point models

There are other kinds of JPMs. All advice languages can be defined in terms of their JPM. For example, a hypothetical aspect language for UML may have the following JPM:

• Join points are all model elements.
• Pointcuts are some boolean expression combining the model elements.
• The means of affect at these points are a visualization of all the matched join points.

Inter-type declarations

Inter-type declarations provide a way to express crosscutting concerns affecting the structure of modules. Also known as open classes and extension methods, this enables programmers to declare in one place members or parents of another class, typically in order to combine all the code related to a concern in one aspect. For example, if a programmer implemented the crosscutting display-update concern using visitors instead, an inter-type declaration using the visitor pattern might look like this in AspectJ:

 aspect DisplayUpdate { void Point.acceptVisitor(Visitor v) { v.visit(this); } // other crosscutting code... } 

This code snippet adds the acceptVisitor method to the Point class.

It is a requirement that any structural additions be compatible with the original class, so that clients of the existing class continue to operate, unless the AOP implementation can expect to control all clients at all times.

Implementation

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

1. a combined program is produced, valid in the original language and indistinguishable from an ordinary program to the ultimate interpreter
2. 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 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, below).

Deploy-time weaving offers another approach.^[7] 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.

Terminology

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^[8] or information flow control.^[9] 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.

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.

Comparison to other programming paradigms

Aspects emerged from object-oriented programming and computational reflection. AOP languages have functionality similar to, but more restricted than metaobject protocols. Aspects relate closely to programming concepts like subjects, mixins, and delegation. Other ways to use aspect-oriented programming paradigms include Composition Filters and the hyperslices approach. Since at least the 1970s, developers have been using forms of interception and dispatch-patching that resemble some of the implementation methods for AOP, but these never had the semantics that the crosscutting specifications provide written in one place.^{[citation needed]}

Designers have considered alternative ways to achieve separation of code, such as C#'s partial types, but such approaches lack a quantification mechanism that allows reaching several join points of the code with one declarative statement.^{[citation needed]}

Though it may seem unrelated, in testing, the use of mocks or stubs requires the use of AOP techniques, like around advice, and so forth. Here the collaborating objects are for the purpose of the test, a cross cutting concern. Thus the various Mock Object frameworks provide these features. For example, a process invokes a service to get a balance amount. In the test of the process, where the amount comes from is unimportant, only that the process uses the balance according to the requirements.^{[citation needed]}

Adoption issues

Programmers need to be able to read code and understand what is happening in order to prevent errors.^[10] Even with proper education, understanding crosscutting concerns can be difficult without proper support for visualizing both static structure and the dynamic flow of a program.^[11] Beginning in 2002, AspectJ began to provide IDE plug-ins to support the visualizing of crosscutting concerns. Those features, as well as aspect code assist and refactoring are now common.

Given the power of AOP, if a programmer makes a logical mistake in expressing crosscutting, it can lead to widespread program failure. Conversely, another programmer may change the join points in a program – e.g., by renaming or moving methods – in ways that the aspect writer did not anticipate, with unforeseen consequences. One advantage of modularizing crosscutting concerns is enabling one programmer to affect the entire system easily; as a result, such problems present as a conflict over responsibility between two or more developers for a given failure. However, the solution for these problems can be much easier in the presence of AOP, since only the aspect needs to be changed, whereas the corresponding problems without AOP can be much more spread out.^{[citation needed]}

Criticism

The most basic criticism of the effect of AOP is that control flow is obscured, and that it is not only worse than the much-maligned GOTO, but is in fact closely analogous to the joke COME FROM statement.^[11] The obliviousness of application, which is fundamental to many definitions of AOP (the code in question has no indication that an advice will be applied, which is specified instead in the pointcut), means that the advice is not visible, in contrast to an explicit method call.^[11][12] For example, compare the COME FROM program:^[11]

 5 INPUT X 10 PRINT 'Result is :' 15 PRINT X 20 COME FROM 10 25 X = X * X 30 RETURN 

with an AOP fragment with analogous semantics:

main() { input x print(result(x)) } input result(int x) { return x } around(int x): call(result(int)) && args(x) { int temp = proceed(x)  return temp * temp } 

Indeed, the pointcut may depend on runtime condition and thus not be statically deterministic. This can be mitigated but not solved by static analysis and IDE support showing which advices potentially match.

General criticisms are that AOP purports to improve "both modularity and the structure of code", but some counter that it instead undermines these goals and impedes "independent development and understandability of programs".^[13] Specifically, quantification by pointcuts breaks modularity: "one must, in general, have whole-program knowledge to reason about the dynamic execution of an aspect-oriented program."^[14] Further, while its goals (modularizing cross-cutting concerns) are well understood, its actual definition is unclear and not clearly distinguished from other well-established techniques.^[13] Cross-cutting concerns potentially cross-cut each other, requiring some resolution mechanism, such as ordering.^[13] Indeed, aspects can apply to themselves, leading to problems such as the liar paradox.^[15]

Technical criticisms include that the quantification of pointcuts (defining where advices are executed) is "extremely sensitive to changes in the program", which is known as the fragile pointcut problem.^[13] The problems with pointcuts are deemed intractable: if one replaces the quantification of pointcuts with explicit annotations, one obtains attribute-oriented programming instead, which is simply an explicit subroutine call and suffers the identical problem of scattering that AOP was designed to solve.^[13]

Implementations

The following programming languages have implemented AOP, within the language, or as an external library:

• .NET Framework languages (C# / VB.NET)^[16]
  • PostSharp is a commercial AOP implementation with a free but limited edition.
  • Unity provides an API to facilitate proven practices in core areas of programming including data access, security, logging, exception handling and others.
• ActionScript^[17]
• Ada^[18]
• AutoHotkey^[19]
• C / C++^[20]
• COBOL^[21]
• The Cocoa Objective-C frameworks^[22]
• ColdFusion^[23]
• Common Lisp^[24]
• Delphi^[25][26][27]
• Delphi Prism^[28]
• e (IEEE 1647)
• Emacs Lisp^[29]
• Groovy
• Haskell^[30]
• Java^[31]
  • AspectJ
• JavaScript^[32]
• Logtalk^[33]
• Lua^[34]
• make^[35]
• Matlab^[36]
• ML^[37]
• Nemerle^[38]
• Perl^[39]
• PHP^[40]
• Prolog^[41]
• Python^[42]
• Racket^[43]
• Ruby^[44][45][46]
• Squeak Smalltalk^[47][48]
• UML 2.0^[49]
• XML^[50]

See also

• Distributed AOP
• Attribute grammar, a formalism that can be used for aspect-oriented programming on top of functional programming languages
• Programming paradigms
• Subject-oriented programming, an alternative to Aspect-oriented programming
• Role-oriented programming, an alternative to Aspect-oriented programming
• Predicate dispatch, an older alternative to Aspect-oriented programming
• Executable UML
• Decorator pattern
• Domain-driven design

Notes and references

1. Kiczales, G.; Lamping, J.; Mendhekar, A.; Maeda, C.; Lopes, C.; Loingtier, J. M.; Irwin, J. (1997). Aspect-oriented programming (PDF). ECOOP'97. Proceedings of the 11th European Conference on Object-Oriented Programming. LNCS. Vol. 1241. pp. 220–242. CiteSeerX 10.1.1.115.8660. doi:10.1007/BFb0053381. ISBN 3-540-63089-9. (PDF) from the original on 12 January 2016.
2. "Adaptive Object Oriented Programming: The Demeter Approach with Propagation Patterns" Karl Liebherr 1996 ISBN 0-534-94602-X presents a well-worked version of essentially the same thing (Lieberherr subsequently recognized this and reframed his approach).
3. Don Box; Chris Sells (4 November 2002). Essential.NET: The common language runtime. Addison-Wesley Professional. p. 206. ISBN 978-0-201-73411-9. Retrieved 4 October 2011.
4. Roman, Ed; Sriganesh, Rima Patel; Brose, Gerald (1 January 2005). Mastering Enterprise JavaBeans. John Wiley and Sons. p. 285. ISBN 978-0-7645-8492-3. Retrieved 4 October 2011.
5. Note: The examples in this article appear in a syntax that resembles that of the Java language.
6. "gnu.org". www.gnu.org. from the original on 24 December 2017. Retrieved 5 May 2018.
7. (PDF). Archived from the original (PDF) on 8 October 2005. Retrieved 19 June 2005.{{cite web}}: CS1 maint: archived copy as title (link)
8. B. De Win, B. Vanhaute and B. De Decker. "Security through aspect-oriented programming". In Advances in Network and Distributed Systems Security (2002).
9. 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).
10. Edsger Dijkstra, Notes on Structured Programming 2006-10-12 at the Wayback Machine, pg. 1-2
11. Constantinides, Constantinos; Skotiniotis, Therapon; Störzer, Maximilian (September 2004). AOP Considered Harmful (PDF). European Interactive Workshop on Aspects in Software (EIWAS). Berlin, Germany. (PDF) from the original on 23 March 2016. Retrieved 5 May 2018.
12. C2:ComeFrom
13. Steimann, F. (2006). "The paradoxical success of aspect-oriented programming". ACM SIGPLAN Notices. 41 (10): 481–497. CiteSeerX 10.1.1.457.2210. doi:10.1145/1167515.1167514., (slides 2016-03-04 at the Wayback Machine,slides 2 2015-09-23 at the Wayback Machine, abstract 2015-09-24 at the Wayback Machine), Friedrich Steimann, Gary T. Leavens, OOPSLA 2006
14. "More Modular Reasoning for Aspect-Oriented Programs". from the original on 12 August 2015. Retrieved 11 August 2015.
15. "AOP and the Antinomy of the Liar" (PDF). fernuni-hagen.de. (PDF) from the original on 9 August 2017. Retrieved 5 May 2018.
16. Numerous: Afterthought 2016-03-15 at the Wayback Machine, LOOM.NET 2008-08-27 at the Wayback Machine, Enterprise Library 3.0 Policy Injection Application Block 2007-01-19 at the Wayback Machine, AspectDNG 2004-09-29 at the Wayback Machine, DynamicProxy 2015-12-05 at the Wayback Machine, Compose* Archived 2005-08-21 at Wikiwix, PostSharp 2016-05-03 at the Wayback Machine, Seasar.NET 2006-07-25 at the Wayback Machine, DotSpect (.SPECT) 2006-03-31 at the Wayback Machine, Spring.NET 2006-04-02 at the Wayback Machine (as part of its functionality), Wicca and Phx.Morph 2006-12-07 at the Wayback Machine, SetPoint 2008-10-07 at the Wayback Machine
17. "Welcome to as3-commons-bytecode". as3commons.org. from the original on 3 October 2014. Retrieved 5 May 2018.
18. "Ada2012 Rationale" (PDF). adacore.com. (PDF) from the original on 18 April 2016. Retrieved 5 May 2018.
19. "Function Hooks". autohotkey.com. Archived from the original on 17 January 2013. Retrieved 5 May 2018.
20. Several: AspectC++, FeatureC++, AspectC 2006-08-21 at the Wayback Machine, AspeCt-oriented C 2008-11-20 at the Wayback Machine, Aspicere
21. "Cobble". vub.ac.be. Retrieved 5 May 2018.^{[permanent dead link]}
22. . neu.edu. Archived from the original on 26 October 2007. Retrieved 5 May 2018.
23. . 5 November 2005. Archived from the original on 5 November 2005. Retrieved 5 May 2018.{{cite web}}: CS1 maint: bot: original URL status unknown (link)
24. "Closer Project: AspectL". Archived from the original on 23 February 2011. Retrieved 11 August 2015.
25. "infra - Frameworks Integrados para Delphi - Google Project Hosting". from the original on 9 September 2015. Retrieved 11 August 2015.
26. "meaop - MeSDK: MeObjects, MeRTTI, MeAOP - Delphi AOP(Aspect Oriented Programming), MeRemote, MeService... - Google Project Hosting". from the original on 10 September 2015. Retrieved 11 August 2015.
27. "Google Project Hosting". from the original on 25 December 2014. Retrieved 11 August 2015.
28. . codegear.com. Archived from the original on 23 January 2012. Retrieved 5 May 2018.
29. "Emacs Advice Functions". gnu.org. from the original on 24 October 2011. Retrieved 5 May 2018.
30. Monads allow program semantics to be altered by changing the type of the program without altering its code: De Meuter, Wolfgang (1997). "Monads As a theoretical basis for AOP". International Workshop on Aspect-Oriented Programming at ECOOP: 25. CiteSeerX 10.1.1.25.8262. Tabareau, Nicolas; Figueroa, Ismael; Tanter, Éric (March 2013). "A Typed Monadic Embedding of Aspects". Proceedings of the 12th Annual International Conference on Aspect-oriented Software Development. Aosd '13: 171–184. doi:10.1145/2451436.2451457. ISBN 9781450317665. S2CID 27256161. Type classes allow additional capabilities to be added to a type: Sulzmann, Martin; Wang, Meng (March 2007). "Aspect-oriented programming with type classes". Proceedings of the 6th Workshop on Foundations of Aspect-oriented Languages: 65–74. doi:10.1145/1233833.1233842. ISBN 978-1595936615. S2CID 3253858..
31. Numerous others: CaesarJ 2008-12-19 at the Wayback Machine, Compose* Archived 2005-08-21 at Wikiwix, Dynaop 2007-07-24 at the Wayback Machine, JAC 2004-06-19 at the Wayback Machine, Google Guice (as part of its functionality), Javassist 2004-09-01 at the Wayback Machine, JAsCo (and AWED) 2005-04-11 at the Wayback Machine, JAML 2005-04-15 at the Wayback Machine, JBoss AOP 2006-10-17 at the Wayback Machine, LogicAJ 2006-05-04 at the Wayback Machine, Object Teams 2005-08-31 at the Wayback Machine, PROSE 2007-01-24 at the Wayback Machine, The AspectBench Compiler for AspectJ (abc) 2014-12-16 at the Wayback Machine, Spring framework (as part of its functionality), Seasar, The JMangler Project 2005-10-28 at the Wayback Machine, InjectJ 2005-04-05 at the Wayback Machine, GluonJ 2007-02-06 at the Wayback Machine, Steamloom 2007-08-18 at the Wayback Machine
32. Many: Advisable 2008-07-04 at the Wayback Machine, Ajaxpect 2016-07-09 at the Wayback Machine, jQuery AOP Plugin 2008-01-13 at the Wayback Machine, Aspectes Archived 2006-05-08 at Wikiwix, AspectJS 2008-12-16 at the Wayback Machine, Cerny.js 2007-06-27 at the Wayback Machine, Dojo Toolkit 2006-02-21 at the Wayback Machine, Humax Web Framework 2008-12-09 at the Wayback Machine, Joose 2015-03-18 at the Wayback Machine, Prototype - Prototype Function#wrap 2009-05-05 at the Wayback Machine, YUI 3 (Y.Do) 2011-01-25 at the Wayback Machine
33. Using built-in support for categories (which allows the encapsulation of aspect code) and event-driven programming (which allows the definition of before and after event handlers).
34. "AspectLua". from the original on 17 July 2015. Retrieved 11 August 2015.
35. "MAKAO, re(verse)-engineering build systems". Archived from the original on 24 July 2012. Retrieved 11 August 2015.
36. "McLab". from the original on 24 September 2015. Retrieved 11 August 2015.
37. "AspectML - Aspect-oriented Functional Programming Language Research". from the original on 5 December 2010. Retrieved 11 August 2015.
38. "nemerle/README.md at master · rsdn/nemerle". GitHub. Retrieved 22 March 2018.
39. Adam Kennedy. "Aspect - Aspect-Oriented Programming (AOP) for Perl - metacpan.org". from the original on 31 August 2013. Retrieved 11 August 2015.
40. Several: PHP-AOP (AOP.io) Archived 2014-08-18 at Wikiwix, Go! AOP framework 2013-03-01 at the Wayback Machine, PHPaspect 2016-08-22 at the Wayback Machine, Seasar.PHP 2005-12-26 at the Wayback Machine, PHP-AOP, Flow 2018-01-04 at the Wayback Machine, AOP PECL Extension 2017-04-11 at the Wayback Machine
41. "bigzaphod.org is coming soon". www.bigzaphod.org. from the original on 20 April 2016. Retrieved 5 May 2018.
42. Several: PEAK 2005-04-09 at the Wayback Machine, , Lightweight Python AOP 2004-10-09 at the Wayback Machine, Logilab's aspect module 2005-03-09 at the Wayback Machine, Pythius 2005-04-08 at the Wayback Machine, Spring Python's AOP module 2016-03-04 at the Wayback Machine, Pytilities' AOP module 2011-08-25 at the Wayback Machine, aspectlib 2014-11-05 at the Wayback Machine
43. "PLaneT Package Repository : PLaneT > dutchyn > aspectscheme.plt". from the original on 5 September 2015. Retrieved 11 August 2015.
44. "AspectR - Simple aspect-oriented programming in Ruby". Archived from the original on 12 August 2015. Retrieved 11 August 2015.
45. Dean Wampler. . Archived from the original on 26 October 2007. Retrieved 11 August 2015.
46. "gcao/aspector". GitHub. from the original on 4 January 2015. Retrieved 11 August 2015.
47. . tu-ilmenau.de. Archived from the original on 6 January 2006. Retrieved 5 May 2018.
48. . Archived from the original on 29 July 2015. Retrieved 11 August 2015.
49. "WEAVR". iit.edu. from the original on 12 December 2008. Retrieved 5 May 2018.
50. "aspectxml - An Aspect-Oriented XML Weaving Engine (AXLE) - Google Project Hosting". from the original on 12 September 2015. Retrieved 11 August 2015.

Further reading

• Kiczales, G.; Lamping, J.; Mendhekar, A.; Maeda, C.; Lopes, C.; Loingtier, J. M.; Irwin, J. (1997). Aspect-oriented programming (PDF). ECOOP'97. Proceedings of the 11th European Conference on Object-Oriented Programming. LNCS. Vol. 1241. pp. 220–242. CiteSeerX 10.1.1.115.8660. doi:10.1007/BFb0053381. ISBN 3-540-63089-9. The paper generally considered to be the authoritative reference for AOP.
• Robert E. Filman; Tzilla Elrad; Siobhán Clarke; Mehmet Aksit (2004). Aspect-Oriented Software Development. ISBN 978-0-321-21976-3.
• Renaud Pawlak, Lionel Seinturier & Jean-Philippe Retaillé (2005). Foundations of AOP for J2EE Development. ISBN 978-1-59059-507-7.
• Laddad, Ramnivas (2003). AspectJ in Action: Practical Aspect-Oriented Programming. ISBN 978-1-930110-93-9.
• Jacobson, Ivar; Pan-Wei Ng (2005). Aspect-Oriented Software Development with Use Cases. ISBN 978-0-321-26888-4.
• Aspect-oriented Software Development and PHP, Dmitry Sheiko, 2006
• Siobhán Clarke & Elisa Baniassad (2005). Aspect-Oriented Analysis and Design: The Theme Approach. ISBN 978-0-321-24674-5.
• Raghu Yedduladoddi (2009). Aspect Oriented Software Development: An Approach to Composing UML Design Models. ISBN 978-3-639-12084-4.
• "Adaptive Object-Oriented Programming Using Graph-Based Customization" – Lieberherr, Silva-Lepe, et al. - 1994
• Zambrano Polo y La Borda, Arturo Federico (5 June 2013). "Addressing aspect interactions in an industrial setting: experiences, problems and solutions": 159. doi:10.35537/10915/35861. Retrieved 30 May 2014. {{cite journal}}: Cite journal requires |journal= (help)
• Wijesuriya, Viraj Brian (2016-08-30) Aspect Oriented Development, Lecture Notes, University of Colombo School of Computing, Sri Lanka
• Groves, Matthew D. (2013). AOP in .NET. ISBN 9781617291142.

External links

• Eric Bodden's list of AOP tools in .net framework
• , annual conference on AOP
• AspectJ Programming Guide
• , another Java implementation
• Series of IBM developerWorks articles on AOP
• Laddad, Ramnivas (January 18, 2002). "I want my AOP!, Part 1". JavaWorld. Retrieved 2020-07-20. A detailed series of articles on basics of aspect-oriented programming and AspectJ
• , introduction with RemObjects Taco
• Constraint-Specification Aspect Weaver
• Aspect- vs. Object-Oriented Programming: Which Technique, When?
• Gregor Kiczales, Professor of Computer Science, explaining AOP, video 57 min.
• Aspect Oriented Programming in COBOL 2008-12-17 at the Wayback Machine
• Aspect-Oriented Programming in Java with Spring Framework
• Wiki dedicated to AOP methods on.NET
• Spring AOP and AspectJ Introduction
• AOSD Graduate Course at Bilkent University
• Introduction to AOP - Software Engineering Radio Podcast Episode 106
• Aspect-Oriented programming for iOS and OS X by Manuel Gebele
• DevExpress MVVM Framework. Introduction to POCO ViewModels