Discussions

News: AOP without the buzzwords: The Ted Neward Challenge

  1. Ted Neward gave the AOP panelists at TheServerSide Symposium a challenge. He wanted them to explain what AOP is without using the buzzwords (e.g. cross-cutting, modularize concerns, pointcut, join point, etc). Adrian Colyer took a crack at it. What do you think?

    Read AOP without the buzzwords

    Jon Tirsen has also written about how AOP is not just de-scatter, de-tangle.

    Threaded Messages (26)

  2. Well, that isn't too hard...

    When OOP models things of the real world, AOP models processes and rules. For example, when you have modeled a class BankAccount, you will most likely want to assure that all clients check certain conditions before they carry out a transaction on an instance of BankAccount.

    Now you can either write the checking code into all clients of your class or you can start using nasty design patterns. But the best solution would be to define a rule: Before making a transaction, check this and that.

    AOP is nothing but defining rules and who has to comply to them before or after doing a specific action. And the AOP framework makes sure that all your clients comply to those rules without that you have to code it seperately.

    Markus
  3. using nasty design patterns

    I guess i don't use the nasty ones, you do?

    >AOP is nothing but defining rules and who has to comply
    > to them before or after doing a specific action.

    Where do actions come from then? The aspects you are
    talking about are the actions. They aren't separate.
    I think you should just drop AOP from OOP and just
    compose programs using aspects directly rather than
    maintain the fiction that you are just extending an
    existing program structure.
  4. I thought AOP was more that you coded to interfaces based on the attributes of objects, so your bank account class would be "Tranactible", "Persistable", or "GUI Displayable" so that the various engines responsible for those aspects could act independently. Or maybe I'm confusing that with the new metadata, .net, and my own wishful thinking.

    I don't know about all this bleeding edge stuff though, I'm just a though-poseur who still doesn't get design patterns.
  5. Interesting article and example (Observer pattern). I guess AOP could prevent the 1:N code bloat that accompanies programs with lots of logging code too.
  6. RELATE THE UNRELATED[ Go to top ]

    I see AOP as a way to relate things which initially are not necessarily related, or don't even exist.

    Similar example in math: one defines different concepts, like segment, triangle, rectangle, etc, and their properties are gathered/studied in a separate chapter for each shape. However, the notion of area is defined in a different chapter, where all the previous (and future) shapes are treated. Also, different textbooks will start with different definitions for area (one can start with a 1x1 square to define the unit for area, divide a shape into small rectangles etc., another one can do it differently). There is clearly a benefit in separating this cross-cutting concept, but nothing prevents a report about shapes to provide a formula for the area at the same place where other properties of the shape are shown (this would be similar to an aspect browser).

    Software designs are similar to math/scientific presentations after all both are organizing concepts), and a lot of useful paradigms/patterns can be lifted directly from the latter.
  7. I think many of "AOP concepts" already exist in OO, for example, aspects are about SoC (but incorrectly used only for technical concerns), but in OO this is the concept of domain, if you BankAccount of course the "persistent mechanism" is not about banking, so persistence is another "domain", in the same way a Workflow is a domain itself, different (but cross-cut) with Sale Order domain.

    The major problem is not the concept behind OO but the current implemented solutions, that in many cases breake OO principles. I see AOP ideas interesting but I'm concerning this is about fixing the languages and frameworks with new "brand", the same for "service-oriented architecture", what are this guys are talking about, OO and component development has been about message passing, cohesion and decoupling always. The invocation method (API, SOAP or whatever) is only the way to transport the messages between objects.

    Another thing is about patterns, I think patterns are the key for continuing improvement of software quality, of course there are many stupids patterns around there, but the idea of patterns is really good, so I'm sure you can found stupid designed OO software too.
  8. Main word is obviousness[ Go to top ]

    Copied from www.manageability.org:
    Robert Filman has a boat load of interesting papers about Aspect Oriented Programming (AOP). Well he's got a pretty simple and general definition in one of his papers.

    AOP is the ability to assert quantified statements over programs written by oblivious programmers.

    ...
  9. AOP is the ability to assert quantified statements over programs written by oblivious programmers....
    Well said. The programmers are oblivious of the fact that their programs can be related by a common quantified statement.
  10. How about...[ Go to top ]

    "AOP allows you to add a try catch finally block to any method after the method was originally written":
    try {
     // doSomethingPre();
     // call original method
     // doSomethingPostSuccess()
    } catch {
     // doSomethingPostFailure()
    } finally {
     // doSomethingFinally()
    }

    To make life even simpler, you can define a normal Java interface and integrate that using AOP:
    public interface AOPMethod {
      doSomethingPre();
      doSomethingPostSuccess();
      doSomethingPostFailure();
      doSomethingFinally();
    }

    Using the interface, virtually all the AOP buzzwords disappear ;-) And people start to understand AOP (we implemented AOP at my company using an interface like this, without using an AOP framework)
  11. How about...[ Go to top ]

    "AOP allows you to add a try catch finally block to any method after the method was originally written":try { // doSomethingPre(); // call original method // doSomethingPostSuccess()} catch { // doSomethingPostFailure()} finally { // doSomethingFinally()}To make life even simpler, you can define a normal Java interface and integrate that using AOP:public interface AOPMethod {  doSomethingPre();  doSomethingPostSuccess();  doSomethingPostFailure();  doSomethingFinally();}Using the interface, virtually all the AOP buzzwords disappear ;-) And people start to understand AOP (we implemented AOP at my company using an interface like this, without using an AOP framework)
    I think you are talking about design patterns. There is no problems to use AOP principes without AOP language and AOP framework just helps to do it. I have used OOP without OOP language, it is possible to write procedures using "goto/jump" too ( procedure becomes a design pattern in this code ). AOP just makes things more clear and there is nothing bad to think about it as about design pattern too. A lot of people use plain C and have no problems with design.
  12. OOP is to programming what essentialism is to philosophy - the belief that everything has a true essence; to distinguish between essential qualities and other qualities, an essential quality is one where the object would no longer be of the same type if the quality was removed (cf. the wikipedia definition of essentialism). Our (somewhat arbitrary, or at least context-dependent) decisions as to what is essential to a class perforce reduces other aspects to non-essentials. When we perceive a regularity across the non-essentials of multiple classes we can either a) reorganise our class definitions to incorporate the regularity as an essential (attribute or behaviour), inevitably consigning some existing essentials to oblivion or b) provide an alternative classification that co-exists with the existing one. AOP allows us to classify certain behaviours without abandoning others that we have heretofore considered essential.
  13. the belief that everything has a true essence

    No, it is saying there is a namable abstraction to solve
    a particular software issue in a particular context. There
    isn't anything deeper than that or more general than that.
    Abstractions and implementations
    are composable in many different ways. AOP is one
    such way. It's not the only way. I don't even know
    it's the best way when you have source code.
  14. ...Ted Neward gave the AOP panelists at TheServerSide Symposium a challenge. He wanted them to explain what AOP is without using the buzzwords (e.g. cross-cutting, modularize concerns, pointcut, join point, etc)...


    Hmmm..."Patching the binary"?

    :)

    Brian Neal
    BEA Systems, Inc.
  15. "Patching the binary" is good. "Bullsh*t injection" maybe, freely after Fowlers famous other injection thingy. Or "Hey, I fucked up, I'm gonna inject me some of that crosscutting stuff and hope it'll fix it".
  16. Hmmm..."Patching the binary"? :)
    That's not funny...

    ...but it is probably an accurate summary of how it will be misused :(

    My pessimism is based on some of the abuses of OO and non-OO code that I've seen. (I use the word "code" advisedly). Optimistically, I suppose that means that I don't think AOP will make anything any worse :)
  17. ...Ted Neward gave the AOP panelists at TheServerSide Symposium a challenge. He wanted them to explain what AOP is without using the buzzwords (e.g. cross-cutting, modularize concerns, pointcut, join point, etc)...Hmmm..."Patching the binary"?:)Brian NealBEA Systems, Inc.
    Well said. or Bull Sh*t injection as another poster said!

    I still believe a proper design will solve a lot of problems.
  18. I still believe a proper design will solve a lot of problems.
    I guess that's somehow like what Stroustrup might have been told when he came up with a "C with objects":

    "I still believe a proper design will solve a lot of problems. There is nothing that cannot be realized with function and void pointers if you do it right..." ;-)

    Of course almost everything can be implemented using clever Design Patterns. But is it worth the effort? I don't mean using AOP for fixing code that is poorly designed, as comments like "Patching the binary" or "B*llsh*t Injection" imply, but instead using AOP as an integral part of software design.

    You can of course stick to what you know and ignore everything else. If you're fine with a 1000-pages catalog of design patterns, that's ok, though it somehow remembers me of those guys that only used "The Black Art of C" and refused to learn modeling with objects...

      -Markus
  19. If you're fine with a 1000-pages catalog of design patterns, that's ok, though it somehow remembers me of those guys that only used "The Black Art of C" and refused to learn modeling with objects...  -Markus
    So far, AOP has not made any compelling points to adopt it. Agreed, I am not an AOP expert. I would be happy to learn something that really makes sense to use it.

    But so far, AOP has not made any sense (at least to me!). May be one day, it will make sense, but I have my own doubts about AOP concept's ability to make in roads the way OOP did.

    Call it "The Black Art of Java" or anything. But I will use AOP only if it makes any sense to me :0)
  20. But so far, AOP has not made any sense (at least to me!).
    Very possible you use AOP, but do not know you use it :). If you use "Proxy","Decorator", "Interceptor" or "Filter" design pattren and code generation then it is almost the the same as AOP does in practice, It just helps to do the same as you used before to reduce code duplication.
  21. Of course nobody needs AOP...[ Go to top ]

    As far as I can see the main reason that there is code duplication in projects is because the timelines are so tight that things are just done and not refactored enough to extract the duplications.

    All those times you hear 'just get it working and we will come back to it at a later stage and refactor out any commonalities'...except that time never comes as who has ever heard of a project having time at the end or the middle or any time for that matter to refactor anything.

    Good software takes time...but a project plan in the mix and the quality will drop.

    So after reading what I've wrote for a change....if AOP will give you this from the beginning then maybe it has some merit!?
  22. J2EE sans buzzwords[ Go to top ]

    What about J2EE without the buzzwords? Or, how would you describe J2EE to your (proverbial) mother-in-law?
  23. So how about getting rid of the buzzwords altogether. They are unnecessary, hard to understand and only serve to complicate what could be a simple explanation of some systems functionality.

    Buzzwords while useful for sales/marketing types to justify and high cost of the software and baffle the client into thinking they are getting something fantastic, should have no place in normal language.

    Everything can be explained in simpler terms, and it doesnt mean that you are not intelligent if you use simle and straightforward language, only it makes you look like you are trying to be intelligent by throwing useless 'buzzwords' and phrases around the place.

    I love java and technology in general and am proud of what I do but it embarrases me when you hear such sh*t as (e.g. cross-cutting, modularize concerns, pointcut, join point) over the watercooler in the kitchen.

    These words were invented by people who are trying to make themselves out to be better/more intelligent than the rest of us.

    TO complicate something id far easier than to simplify it down so that everyone can understand, discuss and use it. Getrid of the pretentiousness and just develop.
  24. I do not think AOP terms are just buzzwords,
    they are well defined like OOP terms, it is more about computer science, but if is very good if you can explain it in "popular" terms, I like simple and clear things too. As I understand buzzword is something "undefined" invented to confuse people and to sell technology as some kind of magic.
  25. The problem is not buzz words. After all every profession got its own buzzwords.

    But the problem is, despite my interest to learn AOP, b'cos so many people are crying that AOP is the next best thing after sliced bread or next best invention after wheel, the coolest killer technology etc, I was struggling to make any sense out of it.

    Call me a stupid or anything you like, but still AOP does not make any sense to use it!
  26. Agreed. The days of just adopting a technology because it's 'cool' to do so are gone.

    A technology has to have a clear purpose that will compliment something already in existence or improve on some deficiency in whats out there at the moment.

    As far as I can see AOP is in this category....'next best thing'...well explain it in real terms, show us where and how it will improve on what we've got and then maybe it will get adopted...if it is good enough and makes sense.
  27. As far as I can see AOP is in this category....'next best thing'...well explain it in real terms, show us where and how it will improve on what we've got and then maybe it will get adopted...if it is good enough and makes sense.
    It is possible to explain it in very trivial way, AOP just reduces code duplication, you can do the same with your favorite design patterns, AOP just helps to do it. It is possible to explain it by analogy and by example:

    void doSomethig() throws SomethingWrongException {
     try{
       Transaction tx = lookupTransaction();
       Resource resource = lookupResource();
      try{
       Query query = resource.getQuery(QUERY_STRING);
        try{

          resource.removeAll(query.execute());
          tx.commit();

         }finally{
           query.close();
         }

      }cath(Exception e){
     
        tx.rollback();
        throw e;

      }finally{
          resource.close();
      }
      }cath(Exception e){
         throw new SomethingWrongException(e);
      }
    }

    Ugly code to do trivial things, is not it ? It will be more ugly if I will implement a few hundred this kind of methods in some application
    ( realistic project, is not it ? ).

    AOP must help to write it this way:

    void justDoIt() {

       //probably it is not a very good idea
      // to retrieve something for remove :)

       remove(execute(QUERY_STRING));
    }

    You can do it without any clever framework or programming language, but AOP must help to do it.