Who invented aspect oriented programming

By presenting new mechanisms that enable better modularization in a number of systems, AOP is driving us to ask fundamental questions about what modularity should mean in our field. In the past, we have tended to think of modularity in terms of hierarchies of crisply defined blocks, where each block or module defines its interface with the surrounding modules. This idea seems attractive but experience tells us that it is hard to actually get the modularity of the software we build just right.

Some issues are hard to code or design in a single module, others just don't seem to want to stay where you put them. Work in AOP and other areas suggests a different conception of modularity, based on crosscutting structures and a more fluid notion of module boundaries.

The talk will present existing AOP techniques and the problems they solve, as well as open practical and research problems ranging from mechanisms to applications, theoretical formulations, and conceptual foundations. His work is directed at enabling programmers to write programs that, as much as possible, look like their design. He has pursued this goal in a number of projects, including CLOS and its metaobject protocol, open implementations of system software and middleware, and aspect-oriented programming.

You would have to inject all the logging dependencies in your models. Since logging is nothing that a domain model should care about, this is an example of a non-functional requirement and a so-called cross-cutting concern.

With AOP, the code inside your model would know nothing about logging. It will just concentrate on the business logic. The logging is now done from an AOP aspect. The expression after the before tag tells the AOP framework to which method calls this action should be applied. As you can see the advice has full access to the actual method call, the join point , with information about the class, the method and method arguments.

At the first and the second, third, … glance, the terms used in the AOP context are not really intuitive. But, similar to most of the other AOP frameworks, we better stick to them, to keep a common language between developers.

Here they are:. Aspect-Oriented Programming was, of course, not invented by us [2]. Since the initial release of the concept, dozens of implementations for various programming languages evolved. Although a few PHP-based AOP frameworks do exist, they followed concepts which did not match the goals of Flow to provide a powerful, yet developer-friendly solution when the development of Neos began.

In a few cases this even lead to new features or simplifications because they were easier to implement in PHP compared to Java. Flow pragmatically implements a reduced subset of AOP, which satisfies most needs of web applications.

The join point model allows for intercepting method executions but provides no special support for advising field access [3]. Pointcut expressions are based on well-known regular expressions instead of requiring the knowledge of a dedicated expression language. Pointcut filters and join point types are modularized and can be extended if more advanced requirements should arise in the future. However, it does require the Object Manager to fulfill its task.

In accordance to the GoF patterns [4] , the proxy classes act as a placeholders for the target object. They are true subclasses of the original and override adviced methods by implementing an interceptor method. The proxy classes are generated automatically by the AOP framework and cached for further use. If a class has been adviced by some aspect, the Object Manager will only deliver instances of the proxy class instead of the original.

The approach of storing generated proxy classes in files provides the whole advantage of dynamic weaving with a minimum performance hit. Debugging of proxied classes is still easy as they truly exist in real files. Aspects are abstract containers which accommodate pointcut-, introduction- and advice declarations. In most frameworks, including Flow, aspects are defined as plain classes which are tagged annotated as an aspect. The following example shows the definition of a hypothetical FooSecurity aspect:.

What makes it an aspect is solely the Aspect annotation mentioned in the class comment. The AOP framework recognizes this tag and registers the class as an aspect. With Flow classes that are marked final can be targeted by AOP advices by default. If we want to add security to foo, we need a method which carries out the security checks and a definition where and when this method should be executed.

You can either define the pointcut in the advice declaration or set up named pointcuts to help clarify their use. A named pointcut is represented by a method of an aspect class. It contains two pieces of information: The pointcut name, defined by the method name, and the pointcut expression, declared by an annotation. As already mentioned, the pointcut expression configures the filters which are used to match against join points.

It is comparable to an if condition in PHP: Only if the whole condition evaluates to true, the statement is executed - otherwise it will be just ignored. If a pointcut expression evaluates to true, the pointcut matches and advices which refer to this pointcut become active. The AOP framework AspectJ provides a complete pointcut language with dozens of pointcut types and expression constructs. Flow makes do with only a small subset of that language, which we think already suffice for even complex enterprise applications.

A pointcut expression always consists of two parts: The poincut designator and its parameter s. The following designators are supported by Flow:. The method designator matches on the execution of methods with a certain name. The parameter specifies the class and method name, regular expressions can be used for more flexibility [5].

It follows the following scheme:. Specifying the visibility modifier public or protected is optional - if none is specified, both visibilities will match. The class- and method name can be specified as a regular expression. It is not possible to match for interfaces within the method pointcut expression. MyPackage :. They rather use a more fine grained approach with designators such as execution, call and cflow.

As Flow only supports matching to method execution join points anyway, we decided to simplify things by allowing only a more general method designator. The following example should give you an idea how this works:. Besides the method arguments you can also access the properties of the current object or a global object like the party that is currently authenticated.

A detailed description of the runtime evaluations possibilities is described below in the section about the evaluate pointcut designator. The class designator matches on the execution of methods defined in a class with a certain name. The parameter specifies the class name, again regular expressions are allowed here. The class designator follows this simple scheme:.

The class pointcut expression does not match interfaces. If you want to match interfaces, use within instead. The within designator matches on the execution of methods defined in a class of a certain type.

A type matches if the class is a subclass of or implements an interface of the given name. The within designator has this simple syntax:. The classAnnotatedWith designator matches on classes which are tagged with a certain annotation. Currently only the actual annotation class name can be matched, arguments of the annotation cannot be specified:.

The methodAnnotatedWith designator matches on methods which are annotated with a certain annotation. Currently only the actual annotation class name can be matched, arguments of the annotation cannot be specified. The syntax of this designator is as follows:. Matches all method which are annotated with a Special annotation:.

The setting designator matches if the given configuration option is set to true, or if an optional given comparison value equals to its configured value. This is helpful to make advices configurable and switch them off in a specific Flow context or just for testing.

You can use this designator as follows:. The evaluate designator is used to execute advices depending on constraints that have to be evaluated during runtime. This could be a specific value for a method argument see the method designator or checking a certain property of the current object or accessing a global object like the currently authenticated party.

In general you can access object properties by the. Here is an example showing the possibilities:. Matches if the property someProperty of someObject which is a property of the current object the object the advice will be executed in is equal to the name of the currently authenticated user:. Matches if the accounts array in the current party object contains the account stored in the myAccount property of the current object:.

If you like you can enter more than one constraint in a single evaluate pointcut designator by separating them with a comma. The evaluate designator will only match, if all its conditions evaluated to true.

It is possible to register arbitrary singletons to be available as global objects with the Flow configuration setting Neos. The custom filter can then be invoked by using the filter designator:.

All pointcut expressions mentioned in previous sections can be combined into a whole expression, just like you may combine parts to an overall condition in an if construct. Nesting expressions with parentheses is not supported but you may refer to other pointcuts by specifying their full name i.

This final example shows how to combine and reuse pointcuts and ultimately build a hierarchy of pointcuts which can be used conveniently in advice declarations:. With the aspect and pointcuts in place we are now ready to declare the advice.