Aspect Oriented Programming (AOP)

[Larry Rix]

Hi All,

I have heard this term before (along with many others). I have come across it again in the Java Spring library framework descriptions. As I am reading about it, the thought comes to me this is equivalent to Agents in Eiffel. Is that a correct assessment?

Cheers,

Larry

[Larry Rix]

It also sounds wildly dangerous to correctness and reliability.

See: https://en.wikipedia.org/wiki/Aspect-oriented_programming

[Larry Rix]

And then I see the notion of "horizontal cross cutting" and I am led immediately to Generics + Agents = AOP, which makes AOP a "clever" thing, but not a needful thing for Eiffel folks. Yes? No?

[Anthony W]

Back when AOP started coming on the scene, I briefly looked into it and then discarded it.

My take away (granted, I'm going off memory of many years ago) was that it was an attempt to repackage OO from objects with appropriately related actions, to actions which applied across multiple objects. It's seems to be a backwards way of viewing the world.

I never kept it in my C# or Java toolkit.

YMMV

Anthony

On Fri, Sep 21, 2018 at 7:12 PM, Larry Rix <lar...@moonshotsoftware.com> wrote:

And then I see the notion of "horizontal cross cutting" and I am led immediately to Generics + Agents = AOP, which makes AOP a "clever" thing, but not a needful thing for Eiffel folks. Yes? No?

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.

[Woland's Cat]

On 22/09/2018 05:32, Anthony W wrote:
> Back when AOP started coming on the scene, I briefly looked into it
> and then discarded it.
>
> My take away (granted, I'm going off memory of many years ago) was
> that it was an attempt to repackage OO from objects with appropriately
> related actions, to actions which applied across multiple objects.
> It's seems to be a backwards way of viewing the world.
>

exactly my own memory.

 - thomas

[Bernd Schoeller]

Hi -

The best way to understand AOP is by starting from the problem, not the solution.

For most problems in programming, we are able to implement them by writing a number of classes or a small library. This localizes the solution to a small proportion of the code base, keeps complexity down, and makes the solution re-usable.

However, the is small a number of problems in programming that always touch a large number of classes. Examples that are often cited are logging, debugging, monitoring or transactional boundaries. In AOP-speak, this is called a "cross-cutting concern".

Now, the advocates of AOP think that this "pollutes" the code, distracts from the actual business logic, and makes it less readable. I somewhat agree to this point.

The suggested solution by AOP is "code weaving", mean that the control-flow of a routine is split into different modules and 'smartly interlaced' at compile time. AOP introduces a large number of new terminology and compilation techniques to implement this.

IMHO, AOP is a too big gun for a too small problem. The list of AOP concerns turns out to be reasonably small and does not justify the added complexity.

Many other techniques have been developed to address the concerns of AOP in simpler way. The Python and Java communities often use annotations, dynamic code injection and similar, platform specific possibilities.

In a pure OO language like Eiffel, there are a number of techniques to address these problems:

- Wrapper classes (implemented through delegation or inheritance) can factor out non-business specific code.
- The observer pattern allows the dynamic addition of code. Now, AOP is normally a compile-time technique, and using a run-time concept like the observer pattern is a bit of an overkill.

In summary, AOP identified an interest area of problems in programming, but the proposed solutions turned out to be too complex and in the end did not survive the test of time.

The fact that they called it "Aspect Oriented Programming", thus demanding the status of an independent programming paradigm, did not help.

Regards,
Bernd

On 09/22/18 01:12, Larry Rix wrote:

And then I see the notion of "horizontal cross cutting" and I am led immediately to Generics + Agents = AOP, which makes AOP a "clever" thing, but not a needful thing for Eiffel folks. Yes? No?

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

[Larry Rix]

This makes good sense to me.

[Carl Langford]

It strikes me that the runtime settings of the assertion violation conditions is an an example of aspect oriented programming. Currently, you can turn on or off things like preconditions or postconditions. It's not too hard to picture a more elaborate version where you could conditionally change these, for example, restricting to a set of classes that the checks would be applied. Or you could add code to be run when the violation occurs, perhaps to create an auto test. A more complete set of contracts could even be created. I would think this sort of programming would be useful for problems dealing with memory management via the entry points of the garbage collector.  

[Bertrand Meyer]

Carl Langford wrote:

> In summary, AOP identified an interest area of problems in programming, but the proposed solutions turned out
> to be too complex and in the end did not survive the test of time. The fact that they called it "Aspect Oriented Programming",
> thus demanding the status of an independent programming paradigm, did not help.

Very good assessment in my opinion. In 2002 I was at a talk from one of the best known people in software engineering who announced that AOP was going to revolutionize the field. I never believed it would. Aspects provide an interesting perspective on programming, an interesting vocabulary (cross-cutting, weaving), but not a comprehensive programming methodology.

By the way, in an Eiffel context we may note that presentations of AOP, in listing potential applications of aspects, ritually invoke (but typically in passing and without deeper analysis) the example of contracts. Back some years ago Stephanie Balzer at ETH decided to investigate this claim, resulting in a paper written with Patrick Eugster and me: http://se.ethz.ch/~meyer/publications/lncs/aspects_contracts.pdf. The study decisively shows that this supposed example does not work: aspects do not crosscut. (Caveat about our paper: it was written too quickly to meet a conference deadline and would have needed an extra pass of proofreading; even the Eiffel texts are occasionally not quite right. My responsibility. But this is just a matter of form and the concepts are sound.)

One example of property that does occasionally crosscut is documentation. There is some current research work exploring this notion and the possible consequences on tools.

-- BM  

[Ian Joyner]

I think the usual example of cross-cutting concern is security. Security must be handled at all levels, so it is an aspect of everything.

However, the implementation is so different at each level. For example physically securing cables and equipment at the physical level, to encryption at higher levels. However, the encryption algorithms can still be separate to other object, not built in.

Filtering dubious messages is also a technique that can be applied at several levels, but you will be looking at different aspects of each message.

Certainly, security must be considered everywhere, because an entire system is only as strong as the weakest link.

OO solves these problems generally, whereas AOP is specific, but as far as I can tell adds nothing much.

AOP might also be a reaction to lack of multiple inheritance where aspects can be isolated into small modules.

Ian