Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re^2: Aspect-Oriented Programming: Couple of Short Examples

by adrianh (Chancellor)
on Aug 05, 2003 at 13:43 UTC ( #280970=note: print w/ replies, xml ) Need Help??


in reply to Re: Aspect-Oriented Programming: Couple of Short Examples
in thread Aspect-Oriented Programming: Couple of Short Examples

The basic idea behind AOP is separation of concerns. By "concern" I mean, roughly, a "bit of functionality". You want all you logging in one place. You want all your DB functionality in one place. You want all of your persistence layer in one place. Etc.

The basic idea of AOP is that decomposition into classes in a classic OO design/implementation can miss some separation of concerns.

The classic AOP example is logging. If you have a system where you are required to log each method entry and exit you need to do something like:

sub foo { my $self = shift; $self->logger->log('entering foo'); .... $self->logger->log('exiting foo'); };

to every method. This has two problems:

  • It's a lot of monkey coding. Easy to make mistakes. Easy to miss a method out.
  • The "concern" of "every method should log entry and exit" is spread out over the entire codebase. It isn't in one location. If you decide that you only want to log method entry you have to go change every method call.

In AOP you can have a single aspect that says "add this logging code to every method". No monkey coding. No possibility of missing anything. The concern is documented in one place. If you need to change what is logged, or what methods/classes logging should happen in, you only have to change one thing.

Introduction to Aspect Oriented Programming with AspectJ has an overview of some of the Jargon, although (obviously) Java oriented. There is also an mp3 of the lightning talk that Marcel Grunauer gave on Aspect at YAPC::North::America 2001.

AOP can be useful in static languages since it can provide you with a lot of additional flexibility (e.g. you can use AspectJ to add mixins to Java). They are of less relevance to more dynamic languages - especially those with a decent meta-class system. Although, on the Java side, aspects are a compile-time concept so they can be very efficient.

AOP can also make testing and debugging harder (IMO).

I have occasionally found AOP useful in debugging. For example Fun with Hook::LexWrap and code instrumentation could be viewed as AOP.


Comment on Re^2: Aspect-Oriented Programming: Couple of Short Examples
Download Code
Re: Re^2: Aspect-Oriented Programming: Couple of Short Examples
by zby (Vicar) on Aug 05, 2003 at 13:52 UTC
    This looks like a kind of parse tree filter, as opposed to source filter. Whenever you have a function in the tree you add something to it.

      It depends. You can certainly implement it like that (that's basically what things like AspectJ do).

      You can also do it dynamically at runtime (e.g. with Hook::Lexwrap in Perl - which is basically what Aspect does.)

      What a full AOP system gives you is the ability to do it in a structured way - making maintenance less of a nightmare.

        This certainly is programming on the meta level and it seems for me it is like adding some reflectivity to the programs. That's why it fits so well for logging the behaviour of the program.
Re: Re^2: Aspect-Oriented Programming: Couple of Short Examples
by princepawn (Parson) on Aug 05, 2003 at 18:30 UTC
    Perhaps stereotyping the behavior of a set of methods/functions could be handled just as well by Attribute::Handlers ?

    Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality

      That's certainly one approach. You could write something like:

      use My::App::Logging; .... sub foo : Logger { ... };

      and the logging functionality is encapsulated into My::App::Logging, and the attribute handler wraps the method appropriately.

      However, an AOPer would comment that you lose some of the benefits that an aspect based approach would give you:

      • You still have to add the handler to every method you want logged. If you change the policy on what should or should not be logged you still have to do a lot of manual work.
      • You lose the benefit of having the logging "aspect" documented/implemented in one place.
Re: Re^2: Aspect-Oriented Programming: Couple of Short Examples
by chunlou (Curate) on Aug 05, 2003 at 19:52 UTC
    Could you elaborate a bit what you meant by "static language" versus "dynamic language"? I don't think I understand. Thanks.
      Usually, when static vs. dynamic is discussed, it's referring to the typing of the variables. Perl doesn't require that you declare whether you're using a number or a string ahead of time. That's dynamic typing. Static typing is like C or Java, which makes you say "This variable will always be an integer or a float (or whatever)".

      It can also refer to the fact that Perl is (somewhat) introspective, like LISP, while C/C++ is not. You can dynamically generate executable code in Perl, because it's interpreted. You cannot do that in C++. (Well, that's not entirely true, but it's close enough for this discussion.)

      Hope that helps!

      ------
      We are the carpenters and bricklayers of the Information Age.

      The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

      Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

      Could you elaborate a bit what you meant by "static language" versus "dynamic language"? I don't think I understand. Thanks.

      I was searching for a more diplomatic term for the LFSP/LFM divide :-) Perhaps some examples will illustrate.


      In an language with metaclasses you can isolate behaviour to a metaclass in a similar way to the way you move behaviour to an aspect. For example, in Python you could add behaviour to object initialisation by creating a custom __init__ method in a metaclass. See A Primer on Python Metaclass Programming for an examples.

      In languages with eval() like functionality you can make runtime changes to your codebase. Perl developers regularly do code generation at compile time. In languages like Java this is impossible. Aspects give some of this power to Java.

      In languages that support mixins and other forms of multiple implementation inheritance you can separate out some concerns into separate class-hierarchies.


      If you have mixins, metaclasses, macros, runtime access to your language, etc. you find that you need aspects less. Many uses of aspects in languages like Java are to get around issues with Java's design (e.g. the use of AspectJ to create mixins).

      This isn't to say that AOP is a useless or unoriginal concept. There is still the core difference from normal OO code in that an aspect imposes a behaviour on a class, rather than a class requesting behaviour from an aspect.

      However, IMO, the arguments for AOP are less compelling when your language is more flexible.

        Thanks for taking the time to clarify. Sometimes I'm just not sure if someone means "static" vs "dynamic" as defined by dragonchild, or uses it as "diplomatic" term.

        I have nothing for or against AOP. Just found it an interesting item to explore and play with. It's more important to force someone to solve the problem right than to force someone to use a particular tool.

        For example, in Python you could add behaviour to object initialisation by creating a custom __init__ method in a metaclass.

        I'm curious - how do you see Perl or C++ or Java lacking this behavior? I know that my personal baseclass has the following lines in the new() call:

        my $init = $self->can('init'); $init && $init->($self, @_);
        That way, I can define a method init() in every class that derives from this baseclass (which is just a way of encapsulating getter/setter/mutator generation and enforcing attribute creation) and I seem to have the same behavior you're touting Python for ...?

        ------
        We are the carpenters and bricklayers of the Information Age.

        The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

        Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://280970]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (5)
As of 2014-07-12 04:22 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    When choosing user names for websites, I prefer to use:








    Results (238 votes), past polls