Content deleted Content added
m Reverted edits by 2600:1003:B107:CAF6:F565:9BAB:BC7E:C2AF (talk) (HG) (3.3.3) |
Filled in 14 bare reference(s) with reFill () |
||
Line 82:
</source>
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)<ref>
==Join point models==
Line 187:
Programmers need to be able to read code and understand what is happening in order to prevent errors.<ref>[[Edsger Dijkstra]], [http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD249.PDF ''Notes on Structured Programming''], pg. 1-2</ref>
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.<ref>
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.
Line 217:
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".<ref name="steimann">{{Cite journal | doi = 10.1145/1167515.1167514| title = The paradoxical success of aspect-oriented programming| journal = ACM SIGPLAN Notices| volume = 41| issue = 10| pages = 481| year = 2006| last1 = Steimann | first1 = F. }}, ([http://people.dsv.su.se/~johano/ioor/succ_aop.pdf slides],[http://www.eecs.ucf.edu/~leavens/modular-aop/Discussion.pdf slides 2], [http://www.oopsla.org/2006/submission/essays/the_paradoxical_success_of_aspect-oriented_programming.html abstract]), Friedrich Steimann, Gary T. Leavens, [[OOPSLA]] 2006</ref> 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."<ref>{{cite web|url=http://www.eecs.ucf.edu/~leavens/modular-aop/|title=More Modular Reasoning for Aspect-Oriented Programs|publisher=|accessdate=11 August 2015}}</ref> 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.<ref name="steimann"/> Cross-cutting concerns potentially cross-cut each other, requiring some resolution mechanism, such as ordering.<ref name="steimann"/> Indeed, aspects can apply to themselves, leading to problems such as the [[liar paradox]].<ref>
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''.<ref name="steimann"/> 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.<ref name="steimann"/>
Line 227:
**[https://www.postsharp.net/ PostSharp] is a commercial AOP implementation with a free but limited edition.
**[[Unity Application Block|Unity]], It provides an API to facilitate proven practices in core areas of programming including data access, security, logging, exception handling and others.
*[[ActionScript]]<ref>
*[[Ada (programming language)|Ada]]<ref>
*[[AutoHotkey]]<ref>
*[[C (programming language)|C]] / [[C++]]<ref>Several: [[AspectC++]], [http://wwwiti.cs.uni-magdeburg.de/iti_db/forschung/fop/featurec/ FeatureC++], [http://www.cs.ubc.ca/labs/spl/projects/aspectc.html AspectC], [http://www.aspectc.net/ AspeCt-oriented C], [http://www.bramadams.org/aspicere/index.html Aspicere]</ref>
*[[COBOL]]<ref>
*The [[Cocoa (API)|Cocoa]] [[Objective-C]] frameworks<ref>
*[[ColdFusion]]<ref>
*[[Common Lisp]]<ref>{{cite web|url=http://common-lisp.net/project/closer/aspectl.html|title=Closer Project: AspectL.|publisher=|accessdate=11 August 2015}}</ref>
*[[Borland Delphi|Delphi]]<ref>{{cite web|url=https://code.google.com/p/infra/|title=infra - Frameworks Integrados para Delphi - Google Project Hosting|publisher=|accessdate=11 August 2015}}</ref><ref>{{cite web|url=https://code.google.com/p/meaop/|title=meaop - MeSDK: MeObjects, MeRTTI, MeAOP - Delphi AOP(Aspect Oriented Programming), MeRemote, MeService... - Google Project Hosting|publisher=|accessdate=11 August 2015}}</ref><ref>{{cite web|url=https://code.google.com/p/delphisorcery/|title=Google Project Hosting|publisher=|accessdate=11 August 2015}}</ref>
*[[Delphi Prism]]<ref>
*[[E (verification language)|e]] (IEEE 1647)
*[[Emacs Lisp]]<ref>
*[[Groovy (programming language)|Groovy]]
*[[Haskell (programming language)|Haskell]]<ref>[[monad (functional programming)]] ({{cite journal | citeseerx = 10.1.1.25.8262 | title = Monads As a theoretical basis for AOP }}) and [http://portal.acm.org/citation.cfm?id=1233842 Aspect-oriented programming with type classes.] [http://dl.acm.org/citation.cfm?id=2451457 A Typed Monadic Embedding of Aspects]</ref>
Line 251:
*[[Perl]]<ref>{{cite web|url=https://metacpan.org/module/Aspect|title=Aspect - Aspect-Oriented Programming (AOP) for Perl - metacpan.org|author=Adam Kennedy|publisher=|accessdate=11 August 2015}}</ref>
*[[PHP]]<ref>Several: [http://aop.io PHP-AOP (AOP.io)], [http://go.aopphp.com Go! AOP framework], [https://code.google.com/p/phpaspect/ PHPaspect], [http://www.seasar.org/en/php5/index.html Seasar.PHP], [http://php-aop.googlecode.com/ PHP-AOP], [https://flow.neos.io/ Flow], [https://github.com/AOP-PHP/AOP AOP PECL Extension]</ref>
*[[Prolog]]<ref>
*[[Python (programming language)|Python]]<ref>Several: [http://peak.telecommunity.com/ PEAK], [http://old.aspyct.org Aspyct AOP], [http://www.cs.tut.fi/~ask/aspects/aspects.html Lightweight Python AOP], [http://www.logilab.org/projects/aspects Logilab's aspect module], [http://pythius.sourceforge.net/ Pythius], [http://springpython.webfactional.com/1.1.x/reference/html/aop.html Spring Python's AOP module], [http://pytilities.sourceforge.net/doc/1.1.0/guide/aop/ Pytilities' AOP module], [http://python-aspectlib.readthedocs.org/en/latest/ aspectlib]</ref>
*[[Racket (programming language)|Racket]]<ref>{{cite web|url=http://planet.racket-lang.org/display.ss?package=aspectscheme.plt&owner=dutchyn|title=PLaneT Package Repository : PLaneT > dutchyn > aspectscheme.plt|publisher=|accessdate=11 August 2015}}</ref>
*[[Ruby (programming language)|Ruby]]<ref>{{cite web|url=http://aspectr-fork.sourceforge.net/|title=AspectR - Simple aspect-oriented programming in Ruby|publisher=|accessdate=11 August 2015}}</ref><ref>{{cite web|url=http://aquarium.rubyforge.org/|title=Home|author=Dean Wampler|publisher=|accessdate=11 August 2015}}</ref><ref>{{cite web|url=https://github.com/gcao/aspector|title=gcao/aspector|work=GitHub|accessdate=11 August 2015}}</ref>
*[[Squeak]] [[Smalltalk]]<ref>
*[[UML 2|UML 2.0]]<ref>
*[[XML]]<ref>{{cite web|url=https://code.google.com/p/aspectxml/|title=aspectxml - An Aspect-Oriented XML Weaving Engine (AXLE) - Google Project Hosting|publisher=|accessdate=11 August 2015}}</ref>
| |||