Aspect-oriented programming

src: i.ytimg.com

In computing, aspect-oriented programming ( AOP ) is a programming paradigm that aims to increase modularity by allowing the separation of cross-cutting issues. It does so by adding additional behavior to the existing code (suggestions) without modifying the code itself, instead of separately specifying the code modified via the "pointcut" specification, such as "log all call functions when the function name starts with 'set' ". This allows unnecessary behavior for business logic (such as logging) to be added to the program without messing up the code, core to functionality. AOP forms the basis for aspect-oriented software development.

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

Aspect-oriented programming requires breaking program logic into different parts (called problem , cohesive functional area). Almost all programming paradigms support multiple levels of grouping and encapsulation of concerns into separate and independent entities by providing abstractions (eg, functions, procedures, modules, classes, methods) that can be used to apply, abstract and construct this problem. Some concerns "cut off" some abstractions in a program, and opposed these forms of implementation. These concerns are called cross-cutting issues or horizontal issues.

Logging exemplifies cross-border concerns because logging strategies always affect every login part of the system. Logging thus crosscuts all classes and login methods.

All AOP implementations have multiple cutting expressions that confine every concern in one place. The difference between implementations lies in the strength, security, and usefulness of the constructs provided. For example, interceptors who define methods to intercept express a limited form of crosscutting, without much support for safety-type or debugging. AspectJ has a number of such expressions and encapsulates them in a special class, an aspect. For example, an aspect may change the behavior of the base code (non-aspect portion of a program) by applying suggestions (additional behavior) at various points of join (point in the program) specified in quantification or queries called pointcut (which detects whether the points join point given). An aspect can also make binary-compatible structural changes to other classes, such as adding members or parents.

Video Aspect-oriented programming

Histori

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

Gregor Kiczales and colleagues at Xerox PARC developed the AOP explicit concept, and followed this with the expansion of AOP AspectJ into Java. The IBM research team pursued a tool approach over the language design approach and in 2001 proposed Hyper/J and Environment Fraud Manipulation, which has not yet seen extensive use.

The examples in this article use AspectJ.

The Microsoft Transaction Server is considered the first major application of AOP followed by Enterprise JavaBeans.

Maps Aspect-oriented programming

Motivation and basic concepts

Usually, an aspect is scattered or wrinkled as code, making it more difficult to understand and maintain. These are scattered based on functions (such as logging) scattered across a number of unrelated functions that might use function , possibly in completely unrelated systems, different source languages ​​etc. That means changing. logging can require modification of all affected modules. Aspects become tangled not only with the main line function of the system in which they are expressed but also with each other. That means changing one concern requires understanding all the confusing problems or having some way by which the effect of change can be inferred.

For example, consider banking applications with a very simple method of transferring amounts from one account to another:

However, this transfer method ignores certain considerations required by the deployed application: it has no security checks to verify that the user is currently authorized to perform this operation; database transactions must encapsulate operations to prevent unintentional data loss; for diagnostics, the operation should be logged to the system log, etc.

The version with all the new worries, for example, can look like this:

In this example, other interests become tangled with basic functions (sometimes called business logic affairs ). Transactions, security and logging all exemplify cross sector issues.

Now consider what happens if we suddenly need to change (for example) security considerations for the application. In the current version of the program, security-related operations appear scattered in many methods, and such changes will require great effort.

AOP tries to solve this problem by allowing programmers to express cross-cutting concerns in a stand-alone module called aspect . Aspects can contain suggestions (code coupled to points specified in the program) and inter-type declarations (structural members added to other classes). For example, the security module may include suggestions that perform a security check before accessing a bank account. Pointcut defines the time (join points) when one can access the bank account, and the code in the suggestion body defines how security checks are implemented. That way, both checks and places can be maintained in one place. Furthermore, a good pointcut can anticipate changes to the program later, so if another developer creates a new method to access the bank account, the suggestion will be applied to the new method when executed.

So for the above example it implements recording in one aspect:

One can consider AOP as a debugging tool or as a user-level tool. Suggestions should be provided for cases where you can not change the function (user level) or do not want to change the function in the production code (debugging).

src: cf.ppt-online.org

Join the point model

Component related suggestions from aspect-oriented languages ​​define the combined point model (JPM). JPM defines three things:

1. When suggestions can run. These are called join points because they are the points in the running program where additional behavior can be joined in handy. The merging point should be addressable and understandable by ordinary programmers to be useful. It should also be stable throughout unnecessary program changes to keep the aspects stable throughout the changes. Many AOP applications support field execution and field references as join points.
2. A way to determine (or measure ) joins a point, called pointcuts . Pointcuts determine whether a point is joined to a given point. The most useful pointcut languages ​​use a syntax like the base language (for example, AspectJ uses Java signatures) and allows reuse through naming and combinations.
3. How to determine the code to run at the merge point. AspectJ calls this suggestion , and can run it before, after, and around the join point. Some implementations also support such things as defining methods in an aspect in another class.

The join-point models can be compared based on the combined joint points, how the joint points are determined, the operations allowed at joint points, and the expressionable structural enhancements.

AspectJ's_join-point_model "> Aspectjoin-point model

• The merging points in AspectJ include calling or executing methods or constructors, initialization classes or objects, read and write access fields, exception handlers, etc. They do not include loops, super calls, throw clauses, some statements, etc.
• Pointcuts are defined by a combination of primitive pointer designers (PCD)).

"Kinded" PCDs match certain types of merge points (for example, method execution) and tend to take inputs like Java signatures. One pointcut like this:

 execution (* set * (*))  

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

PCD "Dynamic" checks the processing time type and the bind variable. As an example,

 this (Point)  

This pointcut matches when the object being executed is an instance of the Point class. Note that unqualified class names can be used through a normal Java type search.

"Coverage" PCD limits the lexical scope of point of incorporation. As an example:

 in (com.company. *)  

This point matches any merge point in the com.company package. * is a wildcard that can be used to match things with a single signature.

Pointcuts can be compiled and named for reuse. As an example:

This dot matches the point of the execution-method merge, if the method name starts with " set " and this is a derivative of the Point in the com.company package. This can be called using the name " set () ".

• The advice set to run on (before, after, or around) the join point (specified by pointcut) of a particular code (specified as code in the method). AOP Runtime automatically invokes Suggestions when the pointcut matches the join point. For example:

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

This effectively determines: "if the connect point set () matches the join point, run Display.update () code after the point merging is complete. "

Other potential combined point model

There is another type of JPM. All language suggestions can be defined in their JPM terms. For example, hypothetical aspect language for UML can have the following JPM:

• Join points are all model elements.
• Pointcuts are some boolean expressions that combine model elements.
• The way to influence on these points is to visualize all the merge points that match.

Inter-type declaration

Inter-type declaration provides a way to express cross-sectoral concerns that affect the module structure. Also known as open classes and extension methods , it allows programmers to declare in one place members or parents from another class, usually to merge all code related to the problem in one aspect. For example, if a programmer implements a crosscutting-view update issue using a visitor instead, inter-type declarations that use visitor patterns may look like this in AspectJ:

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

It is a requirement that each structural addition be compatible with the original class, so that the clients of the existing classes continue to operate, unless AOP implementations can expect to control all clients at any time.

src: i.ytimg.com

Implementation

An AOP program may affect other programs in two different ways, depending on the language and the underlying environment:

1. the merged program is generated, valid in the original language and can not be distinguished from regular programs until the main translator
2. the main interpreter or environment updated to understand and implement AOP features.

The difficulty of changing the environment means that most implementations result in a compatible combination program through a process known as weaving - a special case of program transformation. Weavers aspect of code-oriented code reading and generate object-oriented code in accordance with the integrated aspects. The same AOP language can be implemented through various weaving methods, so the language semantics should not be understood in terms of weaving practices. Only the speed of implementation and its ease of deployment is affected by the combination method used.

The system can apply source-level weavers using preprocessors (such as C implemented initially in CFront) that require access to the source files of the program. However, a well-defined binary form by Java allows the code weavers to work with any Java program in the form of.class-files. The bytecode weavers can be used during the manufacturing process or, if the weave model is per-class, during class loading. AspectJ began with a source-level weaver in 2001, submitted class-based weavers in 2002, and offered support for advanced load time after AspectWerkz integration in 2005.

Any solution that combines the program at runtime should provide a view that separates them correctly to maintain a separate programmer model. Java bytecode support for various source files allows any debugger to step through a clipped.class file correctly in the source editor. However, some third-party decompilers can not process the weaving code because they expect code generated by Javac rather than everything supported by the code form (see also "Criticism", below).

The time channeling offers another approach. This essentially implies post-processing, but instead of patching the generated code, the weaving approach is subclasses of the existing class so that modifications are introduced by overriding methods. The existing classes remain untouched, even at runtime, and all existing tools (debuggers, profilers, etc.) can be used during development. A similar approach has proven itself in the implementation of many Java EE application servers, such as IBM's WebSphere.

Terminology

The standard terminology used in Aspect-oriented programming may include:

Cross-sectoral attention

Although most classes in the 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 the classes in the data access layer and also to the classes in the UI layer each time a thread enters or exits a method. Further concerns can be attributed to security such as access control or information flow control. Although each class has very different main functions, the code required to perform secondary functions is often identical.

Suggestions

This is the additional code you want to apply to an existing model. In our example, this is the recording code we want to apply whenever a thread is in or out of a method.

Pointcut

This is the term given to the point of execution in the application where cross-sectoral concerns need to be applied. In our example, the pointcut is reached when the thread enters a method, and another pointcut is reached when the thread exits the method.

Aspect

The combination of pointcuts and suggestions is called an aspect. In the example above, we added aspects of the recording to our application by defining the dots and providing the correct suggestions.

src: cf.ppt-online.org

Comparison with other programming paradigms

Aspects emerge from object-oriented programming and computational reflection. AOP languages ​​have functions similar to, but more limited than metaobject protocols. Aspects are closely related to programming concepts such as subject, mixin, and delegate. Other ways to use aspect oriented programming paradigms include Composite Filters and hyperslices approach. At least since the 1970s, developers have used forms of interception and patch-delivery that resemble some implementation methods for AOP, but this never has the semantics given crosscutting specifications in one place.

The designers have considered alternative ways of achieving code separation, such as the partial C # type, but such an approach does not have a quantification mechanism that allows reaching points of merging code with a declarative statement.

While it may seem unrelated, in testing, the use of mocks or stubs requires the use of AOP techniques, such as suggestions, and so on. Here the objects that collaborate are for test purposes, cross-cutting attention. Thus various Mock Object frameworks provide these features. For example, a process called service to get the balance amount. In testing the process, where the number is derived is not important, it's just the process of using the balance in accordance with the requirements.

src: i.ytimg.com

Issues of adoption

The programmer must be able to read the code and understand what's going on to prevent errors. Even with proper education, understanding cross-cutting issues can be difficult without proper support to visualize the static structure and dynamic flow of a program. Starting in 2002, AspectJ began providing IDE plug-ins to support cross-sectoral problem visualization. Those features, as well as helpful and refactoring aspect codes are now common.

Given the power of the AOP, if a programmer makes a logical error in expressing crosscutting, it can lead to extensive program failures. Conversely, other programmers can change the point of incorporation in a program - for example, by renaming or moving methods - in ways unanticipated by aspect writers, with unforeseen consequences. One of the advantages of modularizing crosscutting is that it allows one programmer to affect the entire system easily; as a result, such problems arise as a conflict of responsibility between two or more developers for a given failure. However, the solution to this problem can be much easier with the AOP, because only aspects that need to be changed, while the corresponding problems without AOP can be much more dispersed.

src: cf.ppt-online.org

Criticism

The most basic criticism of the AOP effect is that the control stream is obscured, and it's not only worse than the much-maligned GOTO, but it's actually very similar to the COME FROM statement. The forgotten of app , which is fundamental to many AOP definitions (the code has no indication that the suggestion will be applied, which is determined not on the pointcut), means that the suggestion is not visible, unlike the explicit method call. For example, compare COME program FROM:

with AOP fragments with analog semantics:

Indeed, the pointcut may be dependent on the runtime condition and thus not statically deterministic. This can be mitigated but not resolved by static analysis and IDE support that indicate which suggestions are potentially match.

The general criticism is that the AOP aims to improve "both modularity and code structure", but some counter that actually undermines these goals and hampers "independent program development and understanding". Specifically, quantification by pointcuts breaks down modularity: "one must, in general, have a whole program knowledge for reasons about the dynamic execution of an aspect oriented program." Further, while the goal (modularization of cross-sectoral concerns) is well understood, the actual definition is not clear and is not clearly distinguished from other established techniques. Cross-sectoral concerns potentially interconnect one another, requiring multiple resolution mechanisms, such as ordering. Indeed, aspects can apply to themselves, leading to problems such as the paradox of liars.

Technical criticism includes that quantification of pointcuts (defining where the suggestion is executed) is "very sensitive to changes in the program", known as the brittle pointcut problem . Problems with pointcuts are considered stubborn: if one replaces quantified pointcuts with explicit annotations, people get attribute-oriented programming, which is just an explicit call subroutine and suffers from identical problems from scattering designed to be solved by AOP.

src: i.ytimg.com

Implementations

Source of the article : Wikipedia