Loading ...
Sorry, an error occurred while loading the content.

AOP

Expand Messages
  • Sean Gilbertson
    Have any of you used Aspect-Oriented Programming (AOP) in your projects? What do you think about it? -- Sean Gilbertson IT Systems/Software Developer
    Message 1 of 23 , Apr 14, 2005
    • 0 Attachment
      Have any of you used Aspect-Oriented Programming (AOP) in your projects? What do you think about it?

      --
      Sean Gilbertson
      IT Systems/Software Developer
    • Luiz Esmiralha
      Sean, I find the concept very interesting, I tested it but I wouldn t use it in production yet. Why? Almost no one has used it and I don t wat to create
      Message 2 of 23 , Apr 14, 2005
      • 0 Attachment
        Sean,

        I find the concept very interesting, I tested it but I wouldn't use it
        in production yet. Why? Almost no one has used it and I don't wat to
        create obfuscated code for the guys doing the maintenance job.

        Cheers,
        Luiz

        On 4/14/05, Sean Gilbertson <sean_gilbertson@...> wrote:
        >
        >
        > Have any of you used Aspect-Oriented Programming (AOP) in your projects? What do you think about it?
        >
        > --
        > Sean Gilbertson
        > IT Systems/Software Developer
        >
        > To Post a message, send it to: extremeprogramming@...
        >
        > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
        >
        > ad-free courtesy of objectmentor.com
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
      • yahoogroups@jhrothjr.com
        From: Sean Gilbertson To: extremeprogramming@yahoogroups.com
        Message 3 of 23 , Apr 14, 2005
        • 0 Attachment
          From: "Sean Gilbertson"
          <sean_gilbertson.at.fin-rec.com@...>
          To: "extremeprogramming@yahoogroups.com"
          <extremeprogramming.at.yahoogroups.com@...>
          Sent: Thursday, April 14, 2005 2:26 PM
          Subject: [XP] AOP

          > Have any of you used Aspect-Oriented Programming (AOP) in your projects?
          > What do you think about it?

          I think it's a solution looking for a problem that it can
          solve better than the alternatives.

          AOP is good if you have to take an existing product where
          you can't change the code and have to hot-wire it to do
          something new.

          All the other use cases the enthusiasts cite seem to be
          better served by deliberately designed plug-in architectures.

          The biggest problem I've got is that you can't read the
          code and know what's going on unless you can find
          out who's patched in where, and what they're doing
          with it.

          John Roth


          >
          > --
          > Sean Gilbertson
          > IT Systems/Software Developer
          >
          >
          > To Post a message, send it to: extremeprogramming@...
          >
          > To Unsubscribe, send a blank message to:
          > extremeprogramming-unsubscribe@...
          >
          > ad-free courtesy of objectmentor.com
          > Yahoo! Groups Links
          >
          >
          >
          >
          >
          >
          >
          >
        • Sean Gilbertson
          I m still reading AspectJ in Action, and haven t done much code work, but I think what initially got me excited was the possibility of keeping each object s
          Message 4 of 23 , Apr 14, 2005
          • 0 Attachment
            I'm still reading AspectJ in Action, and haven't done much code work, but I think what initially got me excited was the possibility of keeping each object's logic completely unpolluted. A good example of this is a set of classes I was trying to create which would represent an IM service, a chat log, and a contact. Each time I thought I came up with a better design for how to integrate these three (e.g. how/where to put "sendMessage( )") while keeping the code robust anddecoupled, and allowing my controller/UI to get all the information it wanted withough intruding, I was left unsatisfied. There always seemed to be that feeling that "this is a design that will degrade," which would result in forced, unhappy or confusing code. I feel that if I use aspects, I'll be able to do things like: tie the Contact class to the Service class and possibly make the entire system agnostic of it; automatically log messages to and fro, without having any class make sure that happens, or even that they provide the messages to listeners; update my UI with any new information. I mean, aspects seem like they can not only provide an encapsulated and concise way to address "crosscutting" concerns, but that they can also give us a good place to put "tie-up" code. Used in this way, it seems as though you could add functionality completely /cost-free/. In my example, all of the core code is completely agnostic that logging is happening, and in fact are agnostic of their role in the system at all.

            On Thu, Apr 14, 2005 at 02:44:44PM -0500, yahoogroups@... wrote:
            >
            > From: "Sean Gilbertson"
            > <sean_gilbertson.at.fin-rec.com@...>
            > To: "extremeprogramming@yahoogroups.com"
            > <extremeprogramming.at.yahoogroups.com@...>
            > Sent: Thursday, April 14, 2005 2:26 PM
            > Subject: [XP] AOP
            >
            > > Have any of you used Aspect-Oriented Programming (AOP) in your projects?
            > > What do you think about it?
            >
            > I think it's a solution looking for a problem that it can
            > solve better than the alternatives.
            >
            > AOP is good if you have to take an existing product where
            > you can't change the code and have to hot-wire it to do
            > something new.
            >
            > All the other use cases the enthusiasts cite seem to be
            > better served by deliberately designed plug-in architectures.
            >
            > The biggest problem I've got is that you can't read the
            > code and know what's going on unless you can find
            > out who's patched in where, and what they're doing
            > with it.
            >
            > John Roth
            >
            >
            > >
            > > --
            > > Sean Gilbertson
            > > IT Systems/Software Developer
            > >
            > >
            > > To Post a message, send it to: extremeprogramming@...
            > >
            > > To Unsubscribe, send a blank message to:
            > > extremeprogramming-unsubscribe@...
            > >
            > > ad-free courtesy of objectmentor.com
            > > Yahoo! Groups Links
            > >
            > >
            > >
            > >
            > >
            > >
            > >
            > >
            >
            >
            >
            > To Post a message, send it to: extremeprogramming@...
            >
            > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
            >
            > ad-free courtesy of objectmentor.com
            > Yahoo! Groups Links
            >
            >
            >
            >
            >
            >

            --
            Sean Gilbertson
            IT Systems/Software Developer
          • Dean Wampler
            These are the same sorts of arguments that you heard in the early days of OOP. They are both right and wrong ;^) Yes, you can create very obfuscated code and
            Message 5 of 23 , Apr 14, 2005
            • 0 Attachment
              These are the same sorts of arguments that you heard in the early days
              of OOP. They are both right and wrong ;^)

              Yes, you can create very obfuscated code and yes, AOP is a "hammer" that
              should be used for "real nails". I suspect there will be some
              spectacular failures of projects that drank the coolaid, just like we
              say in the early days of OOP.

              However, it's important to note that all the major Java app. server
              vendors, IBM, BEA, and JBoss, as well as the alternative "container"
              projects (especially Spring) have embraced AOP. AOP is a tool for
              managing truly cross-cutting concerns like security, transactions,
              persistence, logging, tracing, etc. There is also some preliminary work
              on how you might implement application logic using AOP in combination
              with OOP. Enterprise applications really suffer from these cross-cutting
              concerns and that's why the server vendors and many of the application
              implementers are interested in AOP.

              With regards to XP, AOP fits into XP projects in just the same sort of
              way that OOP does.

              For more information start with,
              http://www.aosd.net/
              http://www.aspectprogramming.com/

              dean
              http://www.aspectprogramming.com/

              yahoogroups@... wrote:

              >From: "Sean Gilbertson"
              ><sean_gilbertson.at.fin-rec.com@...>
              >To: "extremeprogramming@yahoogroups.com"
              ><extremeprogramming.at.yahoogroups.com@...>
              >Sent: Thursday, April 14, 2005 2:26 PM
              >Subject: [XP] AOP
              >
              >
              >
              >>Have any of you used Aspect-Oriented Programming (AOP) in your projects?
              >>What do you think about it?
              >>
              >>
              >
              >I think it's a solution looking for a problem that it can
              >solve better than the alternatives.
              >
              >AOP is good if you have to take an existing product where
              >you can't change the code and have to hot-wire it to do
              >something new.
              >
              >All the other use cases the enthusiasts cite seem to be
              >better served by deliberately designed plug-in architectures.
              >
              >The biggest problem I've got is that you can't read the
              >code and know what's going on unless you can find
              >out who's patched in where, and what they're doing
              >with it.
              >
              >John Roth
              >
              >
              >
              >
              >>--
              >>Sean Gilbertson
              >>IT Systems/Software Developer
              >>
              >>
              >>To Post a message, send it to: extremeprogramming@...
              >>
              >>To Unsubscribe, send a blank message to:
              >>extremeprogramming-unsubscribe@...
              >>
              >>ad-free courtesy of objectmentor.com
              >>Yahoo! Groups Links
              >>
              >>
              >>
              >>
              >>
              >>
              >>
              >>
              >>
              >>
              >
              >
              >
              >To Post a message, send it to: extremeprogramming@...
              >
              >To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
              >
              >ad-free courtesy of objectmentor.com
              >Yahoo! Groups Links
              >
              >
              >
              >
              >
              >
              >
              >
            • Shane Mingins
              ... Have a look at Spring http://www.springframework.org/ I thought AspectJ requires code added to the class files??? Spring uses XML files. There are a
              Message 6 of 23 , Apr 14, 2005
              • 0 Attachment
                --- Sean Gilbertson <sean_gilbertson@...>
                wrote:
                >
                >
                > I'm still reading AspectJ in Action, and haven't
                > done much code work, but I think what initially got
                > me excited was the possibility of keeping each
                > object's logic completely unpolluted.

                Have a look at Spring http://www.springframework.org/

                I thought AspectJ requires code added to the class
                files??? Spring uses XML files. There are a couple
                of sample chaps at Manning for Spring in Action and
                one shows a logging example.

                We are using Spring for Hibernate and IOC but not AOP
                ... yet.

                Cheers
                Shane




                __________________________________
                Do you Yahoo!?
                Yahoo! Small Business - Try our new resources site!
                http://smallbusiness.yahoo.com/resources/
              • Sean Gilbertson
                No, aspects are completely separate. You /can/ define them within classes (as far as I understand), but I don t think that s typical. Here s an example: /*
                Message 7 of 23 , Apr 14, 2005
                • 0 Attachment
                  No, aspects are completely separate. You /can/ define them within classes (as far as I understand), but I don't think that's typical. Here's an example:

                  /* Book.java */
                  public class Book {
                  private int allDone;

                  public void read( ) {
                  /* .. */

                  allDone = true;
                  }
                  }

                  /* Library.java */
                  public aspect Library {
                  public pointcut reading( ) : call( void Book.read( ) );

                  before( ) : reading( ) {
                  System.out.println( "done reading the book! please return it!" );
                  }
                  }

                  But if you mean that AspectJ introduces code into classes, and therefore requires the uncompiled .java files, then yes I believe that is true.

                  On Thu, Apr 14, 2005 at 01:14:47PM -0700, Shane Mingins wrote:
                  >
                  >
                  > --- Sean Gilbertson <sean_gilbertson@...>
                  > wrote:
                  > >
                  > >
                  > > I'm still reading AspectJ in Action, and haven't
                  > > done much code work, but I think what initially got
                  > > me excited was the possibility of keeping each
                  > > object's logic completely unpolluted.
                  >
                  > Have a look at Spring http://www.springframework.org/
                  >
                  > I thought AspectJ requires code added to the class
                  > files??? Spring uses XML files. There are a couple
                  > of sample chaps at Manning for Spring in Action and
                  > one shows a logging example.
                  >
                  > We are using Spring for Hibernate and IOC but not AOP
                  > ... yet.
                  >
                  > Cheers
                  > Shane
                  >
                  >
                  >
                  >
                  > __________________________________
                  > Do you Yahoo!?
                  > Yahoo! Small Business - Try our new resources site!
                  > http://smallbusiness.yahoo.com/resources/
                  >
                  >
                  > To Post a message, send it to: extremeprogramming@...
                  >
                  > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                  >
                  > ad-free courtesy of objectmentor.com
                  > Yahoo! Groups Links
                  >
                  >
                  >
                  >
                  >
                  >

                  --
                  Sean Gilbertson
                  IT Systems/Software Developer
                • Dean Wampler
                  AspectJ has the ability to weave aspects into jar files; source isn t required. There are alternative aspect toolkits that work in pure java. Usually, you
                  Message 8 of 23 , Apr 14, 2005
                  • 0 Attachment
                    AspectJ has the ability to "weave" aspects into jar files; source isn't
                    required.

                    There are alternative aspect toolkits that work in pure java. Usually,
                    you write aspect code in java and define how to apply the aspects to
                    other code using XML configuration files, as someone already mentioned
                    for the case of Spring.

                    One of these projects is AspectWerkz, which has recently merged with the
                    AspectJ project. The joint team is working on an implementation that
                    supports a pure-java approach using java 5 annotations, as well as the
                    older XML files, to define behavior, in addition to the current AspectJ
                    syntax that extends java syntax.

                    If you're using Spring or JBoss today, you may be using aspects without
                    realizing it, as they use their underlying aspect systems to implement
                    common functionality (e.g., transaction, persistence, and remoting
                    support in the case of JBoss, if I recall correctly...).

                    dean

                    Sean Gilbertson wrote:

                    > No, aspects are completely separate. You /can/ define them within classes (as far as I understand), but I don't think that's typical. Here's an example:
                    >
                    >/* Book.java */
                    >public class Book {
                    > private int allDone;
                    >
                    > public void read( ) {
                    > /* .. */
                    >
                    > allDone = true;
                    > }
                    >}
                    >
                    >/* Library.java */
                    >public aspect Library {
                    > public pointcut reading( ) : call( void Book.read( ) );
                    >
                    > before( ) : reading( ) {
                    > System.out.println( "done reading the book! please return it!" );
                    > }
                    >}
                    >
                    > But if you mean that AspectJ introduces code into classes, and therefore requires the uncompiled .java files, then yes I believe that is true.
                    >
                    >On Thu, Apr 14, 2005 at 01:14:47PM -0700, Shane Mingins wrote:
                    >
                    >
                    >>--- Sean Gilbertson <sean_gilbertson@...>
                    >>wrote:
                    >>
                    >>
                    >>> I'm still reading AspectJ in Action, and haven't
                    >>>done much code work, but I think what initially got
                    >>>me excited was the possibility of keeping each
                    >>>object's logic completely unpolluted.
                    >>>
                    >>>
                    >>Have a look at Spring http://www.springframework.org/
                    >>
                    >>I thought AspectJ requires code added to the class
                    >>files??? Spring uses XML files. There are a couple
                    >>of sample chaps at Manning for Spring in Action and
                    >>one shows a logging example.
                    >>
                    >>We are using Spring for Hibernate and IOC but not AOP
                    >>... yet.
                    >>
                    >>Cheers
                    >>Shane
                    >>
                    >>
                    >>
                    >>
                    >>__________________________________
                    >>Do you Yahoo!?
                    >>Yahoo! Small Business - Try our new resources site!
                    >>http://smallbusiness.yahoo.com/resources/
                    >>
                    >>
                    >>To Post a message, send it to: extremeprogramming@...
                    >>
                    >>To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                    >>
                    >>ad-free courtesy of objectmentor.com
                    >>Yahoo! Groups Links
                    >>
                    >>
                    >>
                    >>
                    >>
                    >>
                    >>
                    >>
                    >
                    >
                    >
                  • yahoogroups@jhrothjr.com
                    From: Sean Gilbertson To: extremeprogramming@yahoogroups.com
                    Message 9 of 23 , Apr 14, 2005
                    • 0 Attachment
                      From: "Sean Gilbertson"
                      <sean_gilbertson.at.fin-rec.com@...>
                      To: "extremeprogramming@yahoogroups.com"
                      <extremeprogramming.at.yahoogroups.com@...>
                      Sent: Thursday, April 14, 2005 3:01 PM
                      Subject: Re: [XP] AOP

                      > I'm still reading AspectJ in Action, and haven't done much code work, but
                      > I think what initially got me excited was the possibility of keeping each
                      > object's logic completely unpolluted. A good example of this is a set of
                      > classes I was trying to create which would represent an IM service, a chat
                      > log, and a contact. Each time I thought I came up with a better design
                      > for how to integrate these three (e.g. how/where to put "sendMessage( )")
                      > while keeping the code robust anddecoupled, and allowing my controller/UI
                      > to get all the information it wanted withough intruding, I was left
                      > unsatisfied. There always seemed to be that feeling that "this is a
                      > design that will degrade," which would result in forced, unhappy or
                      > confusing code.

                      That's a feeling which I basically ignore. It tells me one of two things:
                      either some part of my old "massive design up front" instincts are bothered
                      by it (and probably rightly so if I didn't have the opportunity to do
                      incremental design) or my intuition is telling me that there is a part of
                      the domain I don't really understand well enough to see the really simple
                      and obvious good solution to the problem.

                      I feel quite justified in ignoring it, since I can do incremental design,
                      and since I'm not locked into existing code that can't be redone if needed.

                      > I feel that if I use aspects, I'll be able to do things like: tie the
                      > Contact class to the Service class and possibly make the entire system
                      > agnostic of it; automatically log messages to and fro, without having any
                      > class make sure that happens, or even that they provide the messages to
                      > listeners; update my UI with any new information. I mean, aspects seem
                      > like they can not only provide an encapsulated and concise way to address
                      > "crosscutting" concerns, but that they can also give us a good place to
                      > put "tie-up" code. Used in this way, it seems as though you could add
                      > functionality completely /cost-free/. In my example, all of the core code
                      > is completely agnostic that logging is happening, and in fact are agnostic
                      > of their role in the system at all.

                      Well, logging is one of the four examples that most of the AOP enthusiasts
                      cite, and it happens to be one of the examples that is completely
                      non-intrusive: that is, it can be done so it doesn't disturb the code where
                      it's plugged in (other than timing, which usually isn't a concern.)

                      I don't happen to think that a new approach to inserting logging
                      breakpoints justifies all of the excitement, though.

                      John Roth




                      >
                      > On Thu, Apr 14, 2005 at 02:44:44PM -0500, yahoogroups@... wrote:
                      >>
                      >> From: "Sean Gilbertson"
                      >> <sean_gilbertson.at.fin-rec.com@...>
                      >> To: "extremeprogramming@yahoogroups.com"
                      >> <extremeprogramming.at.yahoogroups.com@...>
                      >> Sent: Thursday, April 14, 2005 2:26 PM
                      >> Subject: [XP] AOP
                      >>
                      >> > Have any of you used Aspect-Oriented Programming (AOP) in your
                      >> > projects?
                      >> > What do you think about it?
                      >>
                      >> I think it's a solution looking for a problem that it can
                      >> solve better than the alternatives.
                      >>
                      >> AOP is good if you have to take an existing product where
                      >> you can't change the code and have to hot-wire it to do
                      >> something new.
                      >>
                      >> All the other use cases the enthusiasts cite seem to be
                      >> better served by deliberately designed plug-in architectures.
                      >>
                      >> The biggest problem I've got is that you can't read the
                      >> code and know what's going on unless you can find
                      >> out who's patched in where, and what they're doing
                      >> with it.
                      >>
                      >> John Roth
                      >>
                      >>
                      >> >
                      >> > --
                      >> > Sean Gilbertson
                      >> > IT Systems/Software Developer
                      >> >
                      >> >
                      >> > To Post a message, send it to: extremeprogramming@...
                      >> >
                      >> > To Unsubscribe, send a blank message to:
                      >> > extremeprogramming-unsubscribe@...
                      >> >
                      >> > ad-free courtesy of objectmentor.com
                      >> > Yahoo! Groups Links
                      >> >
                      >> >
                      >> >
                      >> >
                      >> >
                      >> >
                      >> >
                      >> >
                      >>
                      >>
                      >>
                      >> To Post a message, send it to: extremeprogramming@...
                      >>
                      >> To Unsubscribe, send a blank message to:
                      >> extremeprogramming-unsubscribe@...
                      >>
                      >> ad-free courtesy of objectmentor.com
                      >> Yahoo! Groups Links
                      >>
                      >>
                      >>
                      >>
                      >>
                      >>
                      >
                      > --
                      > Sean Gilbertson
                      > IT Systems/Software Developer
                      >
                      >
                      > To Post a message, send it to: extremeprogramming@...
                      >
                      > To Unsubscribe, send a blank message to:
                      > extremeprogramming-unsubscribe@...
                      >
                      > ad-free courtesy of objectmentor.com
                      > Yahoo! Groups Links
                      >
                      >
                      >
                      >
                      >
                      >
                      >
                      >
                    • Sean Gilbertson
                      Wow, that is good to know about AspectJ. So, functionality can be added as long as you have access to, say, JavaDocs? ... -- Sean Gilbertson IT
                      Message 10 of 23 , Apr 14, 2005
                      • 0 Attachment
                        Wow, that is good to know about AspectJ. So, functionality can be added as long as you have access to, say, JavaDocs?

                        On Thu, Apr 14, 2005 at 03:48:31PM -0500, Dean Wampler wrote:
                        >
                        > AspectJ has the ability to "weave" aspects into jar files; source isn't
                        > required.
                        >
                        > There are alternative aspect toolkits that work in pure java. Usually,
                        > you write aspect code in java and define how to apply the aspects to
                        > other code using XML configuration files, as someone already mentioned
                        > for the case of Spring.
                        >
                        > One of these projects is AspectWerkz, which has recently merged with the
                        > AspectJ project. The joint team is working on an implementation that
                        > supports a pure-java approach using java 5 annotations, as well as the
                        > older XML files, to define behavior, in addition to the current AspectJ
                        > syntax that extends java syntax.
                        >
                        > If you're using Spring or JBoss today, you may be using aspects without
                        > realizing it, as they use their underlying aspect systems to implement
                        > common functionality (e.g., transaction, persistence, and remoting
                        > support in the case of JBoss, if I recall correctly...).
                        >
                        > dean
                        >
                        > Sean Gilbertson wrote:
                        >
                        > > No, aspects are completely separate. You /can/ define them within classes (as far as I understand), but I don't think that's typical. Here's an example:
                        > >
                        > >/* Book.java */
                        > >public class Book {
                        > > private int allDone;
                        > >
                        > > public void read( ) {
                        > > /* .. */
                        > >
                        > > allDone = true;
                        > > }
                        > >}
                        > >
                        > >/* Library.java */
                        > >public aspect Library {
                        > > public pointcut reading( ) : call( void Book.read( ) );
                        > >
                        > > before( ) : reading( ) {
                        > > System.out.println( "done reading the book! please return it!" );
                        > > }
                        > >}
                        > >
                        > > But if you mean that AspectJ introduces code into classes, and therefore requires the uncompiled .java files, then yes I believe that is true.
                        > >
                        > >On Thu, Apr 14, 2005 at 01:14:47PM -0700, Shane Mingins wrote:
                        > >
                        > >
                        > >>--- Sean Gilbertson <sean_gilbertson@...>
                        > >>wrote:
                        > >>
                        > >>
                        > >>> I'm still reading AspectJ in Action, and haven't
                        > >>>done much code work, but I think what initially got
                        > >>>me excited was the possibility of keeping each
                        > >>>object's logic completely unpolluted.
                        > >>>
                        > >>>
                        > >>Have a look at Spring http://www.springframework.org/
                        > >>
                        > >>I thought AspectJ requires code added to the class
                        > >>files??? Spring uses XML files. There are a couple
                        > >>of sample chaps at Manning for Spring in Action and
                        > >>one shows a logging example.
                        > >>
                        > >>We are using Spring for Hibernate and IOC but not AOP
                        > >>... yet.
                        > >>
                        > >>Cheers
                        > >>Shane
                        > >>
                        > >>
                        > >>
                        > >>
                        > >>__________________________________
                        > >>Do you Yahoo!?
                        > >>Yahoo! Small Business - Try our new resources site!
                        > >>http://smallbusiness.yahoo.com/resources/
                        > >>
                        > >>
                        > >>To Post a message, send it to: extremeprogramming@...
                        > >>
                        > >>To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                        > >>
                        > >>ad-free courtesy of objectmentor.com
                        > >>Yahoo! Groups Links
                        > >>
                        > >>
                        > >>
                        > >>
                        > >>
                        > >>
                        > >>
                        > >>
                        > >
                        > >
                        > >
                        >
                        >
                        >
                        > To Post a message, send it to: extremeprogramming@...
                        >
                        > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                        >
                        > ad-free courtesy of objectmentor.com
                        > Yahoo! Groups Links
                        >
                        >
                        >
                        >
                        >
                        >

                        --
                        Sean Gilbertson
                        IT Systems/Software Developer
                      • Jeff Grigg
                        ... I ve been using it recently. Primarily for testing. And primarily for working around issues with 3rd party code that we could not change. I think it
                        Message 11 of 23 , Apr 14, 2005
                        • 0 Attachment
                          >> --- From: "Sean Gilbertson"
                          >>> Have any of you used Aspect-Oriented Programming
                          >>> (AOP) in your projects?

                          >>> What do you think about it?

                          I've been using it recently. Primarily for testing. And primarily
                          for working around issues with 3rd party code that we could not
                          change.

                          I think it shows a lot of promise. But successful application of
                          AOP seems to rely on a foundation of good object-oriented design and
                          strong coding standards. And this can be an issue in many
                          development organizations. ;->


                          --- yahoogroups@... wrote:
                          >> I think it's a solution looking for a problem that it can
                          >> solve better than the alternatives.

                          Of course, if it does, then that would be a good thing. ;->

                          >> AOP is good if you have to take an existing product
                          >> where you can't change the code and have to hot-wire
                          >> it to do something new.

                          Actually, that has been my experience too in recent projects. I
                          think that for AOP to really help, project teams have to get good at
                          OO first. And that can be an issue. ;-> If you're subjected to
                          bad OO, and are prevented from fixing it, then you might have to
                          resort to AOP to work around the design problems you're not allowed
                          to fix. That's not an ideal situation.

                          >> The biggest problem I've got is that you can't read the
                          >> code and know what's going on unless you can find
                          >> out who's patched in where, and what they're doing
                          >> with it.

                          The tools are getting better at that. Eclipse with AspectJ shows
                          code markers in the code to show you where aspects are being
                          applied. So the full functionality of the modified code is visible
                          to you. (Not directly, but you're informed that you need to click
                          to get the full story.)


                          --- Dean Wampler <dean@a...> wrote:
                          > [...] AOP is a tool for managing truly cross-cutting concerns
                          > like security, transactions, persistence, logging, tracing,
                          > etc.

                          AOP seems to be good for security, transactions and persistence.

                          From what I've seen, you'd have to be crazy *not* to use AOP for
                          tracing. (...but, on the other hand, I've yet to see a project that
                          actually needs or even uses tracing, in spite of the large
                          investment in tracing code I see in many projects! ;-)

                          And as for logging... It's often used as a "poster child" for AOP,
                          but I'm still skeptical: By my observation, yes "logging" code is
                          distributed throughout the application, but if done well, the things
                          being logged are different in each location -- raising questions in
                          my mind about the effectiveness of AOP to "solve logging problems."

                          > There is also some preliminary work on how you might implement
                          > application logic using AOP in combination with OOP.

                          I like what it can do to the observer pattern: The business logic
                          can be completely decluttered from any knowledge that some external
                          view may be observing it. That can be a very good thing.

                          I can also think of cases where I wished I had AOP -- to standardize
                          exceptions thrown from CORBA server object methods, for instance.


                          So I see a lot of promise in AOP. And a lot of rope... for
                          projects to shoot themselves in the foot with. ;->
                        • yahoogroups@jhrothjr.com
                          From: Dean Wampler To: extremeprogramming@yahoogroups.com
                          Message 12 of 23 , Apr 14, 2005
                          • 0 Attachment
                            From: "Dean Wampler"
                            <dean.at.aspectprogramming.com@...>
                            To: "extremeprogramming@yahoogroups.com"
                            <extremeprogramming.at.yahoogroups.com@...>
                            Sent: Thursday, April 14, 2005 3:09 PM
                            Subject: Re: [XP] AOP


                            >
                            > These are the same sorts of arguments that you heard in the early days
                            > of OOP. They are both right and wrong ;^)

                            A very dismissive statement, sounding wise and meaning
                            absolutely nothing.

                            > Yes, you can create very obfuscated code and yes, AOP is a "hammer" that
                            > should be used for "real nails". I suspect there will be some
                            > spectacular failures of projects that drank the coolaid, just like we
                            > saw in the early days of OOP.

                            True, but again a statement with no meaning to the basis
                            of the discussion.

                            > However, it's important to note that all the major Java app. server
                            > vendors, IBM, BEA, and JBoss, as well as the alternative "container"
                            > projects (especially Spring) have embraced AOP. AOP is a tool for
                            > managing truly cross-cutting concerns like security, transactions,
                            > persistence, logging, tracing, etc. There is also some preliminary work
                            > on how you might implement application logic using AOP in combination
                            > with OOP. Enterprise applications really suffer from these cross-cutting
                            > concerns and that's why the server vendors and many of the application
                            > implementers are interested in AOP.

                            The fact that everyone is jumping on a bandwagon does not mean
                            that the bandwagon is going anywhere useful, or even that it will
                            manage to survive without crashing. Again, an arguement that sounds
                            interesting, but does not address any concern I brushed by.

                            > With regards to XP, AOP fits into XP projects in just the same sort of
                            > way that OOP does.

                            You can do XP with just about anything. So what? How does
                            that statement address any concerns I have with it?

                            The basic issue is very simple: if you layer a set of external
                            hooks on top of a module, you are now putting dependencies
                            in place that trust that the places you've hooked will stay stable.
                            If they change, everything that has been layered on top of them
                            will have to change.

                            If you want to get my attention, you need to address that
                            concern, and you need to address it realistically. That is,
                            how is AOP any better than simply explicitly putting the
                            hooks into the code in the right places? How is it better than
                            a plugin architecture?

                            One arguement that I'm going to reject out of hand is
                            the one that it addresses historically difficult problems.
                            So does TDD, Simple Design and Refactoring. In other
                            words, you're going to have to make a convincing argument
                            that these _remain_ difficult problems when addressed
                            by a team doing full bore TDD and agressive refactoring
                            to remove duplication.

                            I am, by the way, conversant with many of the standard
                            arguements for AOP; refering me to some more
                            documentation on it simply means you are not taking
                            my discussion as being informed by anything other than
                            ignorance, which is, quite frankly, insulting.

                            John Roth


                            >
                            > For more information start with,
                            > http://www.aosd.net/
                            > http://www.aspectprogramming.com/
                            >
                            > dean
                            > http://www.aspectprogramming.com/
                            >
                            > yahoogroups@... wrote:
                            >
                            >>From: "Sean Gilbertson"
                            >><sean_gilbertson.at.fin-rec.com@...>
                            >>To: "extremeprogramming@yahoogroups.com"
                            >><extremeprogramming.at.yahoogroups.com@...>
                            >>Sent: Thursday, April 14, 2005 2:26 PM
                            >>Subject: [XP] AOP
                            >>
                            >>
                            >>
                            >>>Have any of you used Aspect-Oriented Programming (AOP) in your projects?
                            >>>What do you think about it?
                            >>>
                            >>>
                            >>
                            >>I think it's a solution looking for a problem that it can
                            >>solve better than the alternatives.
                            >>
                            >>AOP is good if you have to take an existing product where
                            >>you can't change the code and have to hot-wire it to do
                            >>something new.
                            >>
                            >>All the other use cases the enthusiasts cite seem to be
                            >>better served by deliberately designed plug-in architectures.
                            >>
                            >>The biggest problem I've got is that you can't read the
                            >>code and know what's going on unless you can find
                            >>out who's patched in where, and what they're doing
                            >>with it.
                            >>
                            >>John Roth
                            >>
                            >>
                            >>
                            >>
                            >>>--
                            >>>Sean Gilbertson
                            >>>IT Systems/Software Developer
                            >>>
                            >>>
                            >>>To Post a message, send it to: extremeprogramming@...
                            >>>
                            >>>To Unsubscribe, send a blank message to:
                            >>>extremeprogramming-unsubscribe@...
                            >>>
                            >>>ad-free courtesy of objectmentor.com
                            >>>Yahoo! Groups Links
                            >>>
                            >>>
                            >>>
                            >>>
                            >>>
                            >>>
                            >>>
                            >>>
                            >>>
                            >>>
                            >>
                            >>
                            >>
                            >>To Post a message, send it to: extremeprogramming@...
                            >>
                            >>To Unsubscribe, send a blank message to:
                            >>extremeprogramming-unsubscribe@...
                            >>
                            >>ad-free courtesy of objectmentor.com
                            >>Yahoo! Groups Links
                            >>
                            >>
                            >>
                            >>
                            >>
                            >>
                            >>
                            >>
                            >
                            >
                            >
                            > To Post a message, send it to: extremeprogramming@...
                            >
                            > To Unsubscribe, send a blank message to:
                            > extremeprogramming-unsubscribe@...
                            >
                            > ad-free courtesy of objectmentor.com
                            > Yahoo! Groups Links
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                          • Dean Wampler
                            I m not as familiar with AspectWerkz, but I believe they use the Jakarta Commons Annotations toolkit for pre-java 5 annotation support. Commons Annotations
                            Message 13 of 23 , Apr 14, 2005
                            • 0 Attachment
                              I'm not as familiar with AspectWerkz, but I believe they use the Jakarta
                              Commons Annotations toolkit for pre-java 5 annotation support. Commons
                              Annotations provides processing of javadoc-like tags to specify behavior
                              (one difference, you use @@ instead of @). This capability is available
                              today. AW also has very good support for weaving aspects at runtime.

                              dean

                              Sean Gilbertson wrote:

                              > Wow, that is good to know about AspectJ. So, functionality can be added as long as you have access to, say, JavaDocs?
                              >
                              >On Thu, Apr 14, 2005 at 03:48:31PM -0500, Dean Wampler wrote:
                              >
                              >
                              >>AspectJ has the ability to "weave" aspects into jar files; source isn't
                              >>required.
                              >>
                              >>There are alternative aspect toolkits that work in pure java. Usually,
                              >>you write aspect code in java and define how to apply the aspects to
                              >>other code using XML configuration files, as someone already mentioned
                              >>for the case of Spring.
                              >>
                              >>One of these projects is AspectWerkz, which has recently merged with the
                              >>AspectJ project. The joint team is working on an implementation that
                              >>supports a pure-java approach using java 5 annotations, as well as the
                              >>older XML files, to define behavior, in addition to the current AspectJ
                              >>syntax that extends java syntax.
                              >>
                              >>If you're using Spring or JBoss today, you may be using aspects without
                              >>realizing it, as they use their underlying aspect systems to implement
                              >>common functionality (e.g., transaction, persistence, and remoting
                              >>support in the case of JBoss, if I recall correctly...).
                              >>
                              >>dean
                              >>
                              >>Sean Gilbertson wrote:
                              >>
                              >>
                              >>
                              >>> No, aspects are completely separate. You /can/ define them within classes (as far as I understand), but I don't think that's typical. Here's an example:
                              >>>
                              >>>/* Book.java */
                              >>>public class Book {
                              >>> private int allDone;
                              >>>
                              >>> public void read( ) {
                              >>> /* .. */
                              >>>
                              >>> allDone = true;
                              >>> }
                              >>>}
                              >>>
                              >>>/* Library.java */
                              >>>public aspect Library {
                              >>> public pointcut reading( ) : call( void Book.read( ) );
                              >>>
                              >>> before( ) : reading( ) {
                              >>> System.out.println( "done reading the book! please return it!" );
                              >>> }
                              >>>}
                              >>>
                              >>> But if you mean that AspectJ introduces code into classes, and therefore requires the uncompiled .java files, then yes I believe that is true.
                              >>>
                              >>>On Thu, Apr 14, 2005 at 01:14:47PM -0700, Shane Mingins wrote:
                              >>>
                              >>>
                              >>>
                              >>>
                              >>>>--- Sean Gilbertson <sean_gilbertson@...>
                              >>>>wrote:
                              >>>>
                              >>>>
                              >>>>
                              >>>>
                              >>>>> I'm still reading AspectJ in Action, and haven't
                              >>>>>done much code work, but I think what initially got
                              >>>>>me excited was the possibility of keeping each
                              >>>>>object's logic completely unpolluted.
                              >>>>>
                              >>>>>
                              >>>>>
                              >>>>>
                              >>>>Have a look at Spring http://www.springframework.org/
                              >>>>
                              >>>>I thought AspectJ requires code added to the class
                              >>>>files??? Spring uses XML files. There are a couple
                              >>>>of sample chaps at Manning for Spring in Action and
                              >>>>one shows a logging example.
                              >>>>
                              >>>>We are using Spring for Hibernate and IOC but not AOP
                              >>>>... yet.
                              >>>>
                              >>>>Cheers
                              >>>>Shane
                              >>>>
                              >>>>
                              >>>>
                              >>>>
                              >>>>__________________________________
                              >>>>Do you Yahoo!?
                              >>>>Yahoo! Small Business - Try our new resources site!
                              >>>>http://smallbusiness.yahoo.com/resources/
                              >>>>
                              >>>>
                              >>>>To Post a message, send it to: extremeprogramming@...
                              >>>>
                              >>>>To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                              >>>>
                              >>>>ad-free courtesy of objectmentor.com
                              >>>>Yahoo! Groups Links
                              >>>>
                              >>>>
                              >>>>
                              >>>>
                              >>>>
                              >>>>
                              >>>>
                              >>>>
                              >>>>
                              >>>>
                              >>>
                              >>>
                              >>>
                              >>>
                              >>
                              >>To Post a message, send it to: extremeprogramming@...
                              >>
                              >>To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                              >>
                              >>ad-free courtesy of objectmentor.com
                              >>Yahoo! Groups Links
                              >>
                              >>
                              >>
                              >>
                              >>
                              >>
                              >>
                              >>
                              >
                              >
                              >
                            • Dean Wampler
                              My intention was not to insult, just to offer a bit of levity (in the first paragraph) and a short answer for the benefit of all the other readers who may not
                              Message 14 of 23 , Apr 14, 2005
                              • 0 Attachment
                                My intention was not to insult, just to offer a bit of levity (in the
                                first paragraph) and a short answer for the benefit of all the other
                                readers who may not be interested in a long discussion of a topic that
                                is a bit off-topic (?). My apologies if you took offense. More below,
                                since you asked....

                                yahoogroups@... wrote:

                                >>These are the same sorts of arguments that you heard in the early days
                                >>of OOP. They are both right and wrong ;^)
                                >>
                                >>
                                >
                                >
                                >
                                I've been around a while and these really are similar arguments that I
                                heard in the early days of widespread OO adoption. They are partly right
                                because you can really do bad work with misapplied tools and poor
                                understanding of them, plus a lack of "wisdom" about appropriate use.
                                With both OOP and AOP the flow of control is less obvious. So, it's
                                wrong to use either if the benefits don't justify the drawbacks. I write
                                mostly procedural Perl code, appropriate for the problems I use it for,
                                but mostly OOP (and more lately, AOP) Java, as those projects have
                                scales that need the modularity tools OOP and AOP provide. The XP idea
                                of "doing the simplest thing that could possible work" has always been
                                important.

                                However, the arguments are partly wrong because, just as the issues with
                                OOP largely evaporated as better tools and understanding evolved, the
                                same thing will happen with AOP. Already, the tools for AspectJ,
                                especially in Eclipse, are quite good, and people are doing real work
                                with it. Learning to think in AOP terms is also essential, just as it
                                was/is for OOP.

                                >A very dismissive statement, sounding wise and meaning
                                >absolutely nothing.
                                >
                                >
                                >
                                >>Yes, you can create very obfuscated code and yes, AOP is a "hammer" that
                                >>should be used for "real nails". I suspect there will be some
                                >>spectacular failures of projects that drank the coolaid, just like we
                                >>saw in the early days of OOP.
                                >>
                                >>
                                >
                                >True, but again a statement with no meaning to the basis
                                >of the discussion.
                                >
                                >
                                In the early 90's, I saw some huge, well-publicized project failures
                                where teams inexperienced with OOP jumped in too quickly and failed
                                badly. I recall a project at Mentor Graphics that was widely discussed
                                in the trade press. Unfortunately, the hype peak of the adoption curve
                                of most technologies is hard to avoid, so I expect we'll the same
                                problems as AOP catches on, followed by some backlash, followed by more
                                sober adoption and evolution.

                                >
                                >
                                >>However, it's important to note that all the major Java app. server
                                >>vendors, IBM, BEA, and JBoss, as well as the alternative "container"
                                >>projects (especially Spring) have embraced AOP. AOP is a tool for
                                >>managing truly cross-cutting concerns like security, transactions,
                                >>persistence, logging, tracing, etc. There is also some preliminary work
                                >>on how you might implement application logic using AOP in combination
                                >>with OOP. Enterprise applications really suffer from these cross-cutting
                                >>concerns and that's why the server vendors and many of the application
                                >>implementers are interested in AOP.
                                >>
                                >>
                                >
                                >The fact that everyone is jumping on a bandwagon does not mean
                                >that the bandwagon is going anywhere useful, or even that it will
                                >manage to survive without crashing. Again, an arguement that sounds
                                >interesting, but does not address any concern I brushed by.
                                >
                                >
                                If you talk to these guys (and I've had the opportunity recently to do
                                that), they will tell you that they aren't adopting AOP because of the
                                hype curve; in fact most of their customers don't know what it is and
                                many don't yet seem very interested in it. Rather, the engineers at the
                                app. server vendors find AOP helps them address their own architecture
                                issues as they support the cross-cutting concerns we've listed already.
                                They've learned to downplay "selling" AOP itself and to just use it to
                                get real work done. That's the best approach, IMHO.

                                >>With regards to XP, AOP fits into XP projects in just the same sort of
                                >>way that OOP does.
                                >>
                                >>
                                >
                                >You can do XP with just about anything. So what? How does
                                >that statement address any concerns I have with it?
                                >
                                >The basic issue is very simple: if you layer a set of external
                                >hooks on top of a module, you are now putting dependencies
                                >in place that trust that the places you've hooked will stay stable.
                                >If they change, everything that has been layered on top of them
                                >will have to change.
                                >
                                >
                                This is a valid criticism of early implementations of AOP. It's received
                                a lot of recent attention in the field. It turns out that Java
                                annotations help a lot by decoupling meta information from actual names,
                                which are fragile. You then write your aspects to be coupled to the meta
                                information, instead, so they are resilent to name changes, etc. More
                                work is definitely needed, however.

                                >If you want to get my attention, you need to address that
                                >concern, and you need to address it realistically. That is,
                                >how is AOP any better than simply explicitly putting the
                                >hooks into the code in the right places? How is it better than
                                >a plugin architecture?
                                >
                                >
                                Despite the issue we just discussed, "inserting code hooks in the right
                                places" is the essential problem AOP is solving. Without diving into too
                                many details, if you look at a typical enterprise application code base,
                                the application logic tends to get lost in all the inserted boilerplate
                                for transactions, security, etc., etc. AOP tries to extract this
                                boilerplate and restore true modularity. An analogy is hiding state and
                                behavior inside objects. You could insert it explicitly where you need
                                it, and as we discussed, sometimes that IS the best thing to do, but in
                                many cases you need the encapsulation.

                                There's one important point about AOP that's worth clarifying. To use
                                the example of logging, yes a logging toolkit can be very modular and
                                your application code can be very modular. The cross-cutting concern
                                problem is that you have to sprinkle logging code all over your
                                application code. Add all the other cross-cutting concerns and then try
                                to make a strategic change to one of them and you get the cascading,
                                global code modifications that result from such "tangled" concern code.
                                AOP tries to solve this problem by pulling out the manually inserted
                                code and providing a way to succinctly define how to "weave" the aspects
                                into other code.

                                >One arguement that I'm going to reject out of hand is
                                >the one that it addresses historically difficult problems.
                                >So does TDD, Simple Design and Refactoring. In other
                                >words, you're going to have to make a convincing argument
                                >that these _remain_ difficult problems when addressed
                                >by a team doing full bore TDD and agressive refactoring
                                >to remove duplication.
                                >
                                >
                                These are somewhat orthogonal tools. Would you argue that the best XP
                                practices eliminate the need for exploiting OOP and other modularity
                                design constructs? The same applies to AOP. It's another modularity tool
                                that complements OOP. The XP practices help you use both more
                                appropriately, etc., etc. If XP reduces the need for "fancy" design
                                tricks like AOP, OOP, patterns, etc., etc., then that's definitely a
                                good thing.

                                >I am, by the way, conversant with many of the standard
                                >arguements for AOP; refering me to some more
                                >documentation on it simply means you are not taking
                                >my discussion as being informed by anything other than
                                >ignorance, which is, quite frankly, insulting.
                                >
                                >
                                No, I'm just trying to point out good sources of information to all the
                                readers on the list who may not know about them and also to keep the
                                message short. The resources on these sites make the arguments better
                                than I can, especially in this forum.

                                >John Roth
                                >
                                >
                                >
                                >
                                >>For more information start with,
                                >>http://www.aosd.net/
                                >>http://www.aspectprogramming.com/
                                >>
                                >>dean
                                >>http://www.aspectprogramming.com/
                                >>
                                >>yahoogroups@... wrote:
                                >>
                                >>
                                >>
                                >>>From: "Sean Gilbertson"
                                >>><sean_gilbertson.at.fin-rec.com@...>
                                >>>To: "extremeprogramming@yahoogroups.com"
                                >>><extremeprogramming.at.yahoogroups.com@...>
                                >>>Sent: Thursday, April 14, 2005 2:26 PM
                                >>>Subject: [XP] AOP
                                >>>
                                >>>
                                >>>
                                >>>
                                >>>
                                >>>>Have any of you used Aspect-Oriented Programming (AOP) in your projects?
                                >>>>What do you think about it?
                                >>>>
                                >>>>
                                >>>>
                                >>>>
                                >>>I think it's a solution looking for a problem that it can
                                >>>solve better than the alternatives.
                                >>>
                                >>>AOP is good if you have to take an existing product where
                                >>>you can't change the code and have to hot-wire it to do
                                >>>something new.
                                >>>
                                >>>All the other use cases the enthusiasts cite seem to be
                                >>>better served by deliberately designed plug-in architectures.
                                >>>
                                >>>The biggest problem I've got is that you can't read the
                                >>>code and know what's going on unless you can find
                                >>>out who's patched in where, and what they're doing
                                >>>with it.
                                >>>
                                >>>John Roth
                                >>>
                                >>>
                                >>>
                                >>>
                                >>>
                                >>>
                                >>>>--
                                >>>>Sean Gilbertson
                                >>>>IT Systems/Software Developer
                                >>>>
                                >>>>
                                >>>>To Post a message, send it to: extremeprogramming@...
                                >>>>
                                >>>>To Unsubscribe, send a blank message to:
                                >>>>extremeprogramming-unsubscribe@...
                                >>>>
                                >>>>ad-free courtesy of objectmentor.com
                                >>>>Yahoo! Groups Links
                                >>>>
                                >>>>
                                >>>>
                                >>>>
                                >>>>
                                >>>>
                                >>>>
                                >>>>
                                >>>>
                                >>>>
                                >>>>
                                >>>>
                                >>>
                                >>>To Post a message, send it to: extremeprogramming@...
                                >>>
                                >>>To Unsubscribe, send a blank message to:
                                >>>extremeprogramming-unsubscribe@...
                                >>>
                                >>>ad-free courtesy of objectmentor.com
                                >>>Yahoo! Groups Links
                                >>>
                                >>>
                                >>>
                                >>>
                                >>>
                                >>>
                                >>>
                                >>>
                                >>>
                                >>>
                                >>
                                >>To Post a message, send it to: extremeprogramming@...
                                >>
                                >>To Unsubscribe, send a blank message to:
                                >>extremeprogramming-unsubscribe@...
                                >>
                                >>ad-free courtesy of objectmentor.com
                                >>Yahoo! Groups Links
                                >>
                                >>
                                >>
                                >>
                                >>
                                >>
                                >>
                                >>
                                >>
                                >>
                                >
                                >
                                >
                                >To Post a message, send it to: extremeprogramming@...
                                >
                                >To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                                >
                                >ad-free courtesy of objectmentor.com
                                >Yahoo! Groups Links
                                >
                                >
                                >
                                >
                                >
                                >
                                >
                                >
                              • yahoogroups@jhrothjr.com
                                From: Dean Wampler To: extremeprogramming@yahoogroups.com
                                Message 15 of 23 , Apr 14, 2005
                                • 0 Attachment
                                  From: "Dean Wampler"
                                  <dean.at.aspectprogramming.com@...>
                                  To: "extremeprogramming@yahoogroups.com"
                                  <extremeprogramming.at.yahoogroups.com@...>
                                  Sent: Thursday, April 14, 2005 5:22 PM
                                  Subject: Re: [XP] AOP


                                  >
                                  > My intention was not to insult, just to offer a bit of levity (in the
                                  > first paragraph) and a short answer for the benefit of all the other
                                  > readers who may not be interested in a long discussion of a topic that
                                  > is a bit off-topic (?). My apologies if you took offense. More below,
                                  > since you asked....

                                  OK.

                                  > yahoogroups@... wrote:
                                  >
                                  >>>These are the same sorts of arguments that you heard in the early days
                                  >>>of OOP. They are both right and wrong ;^)
                                  >>>
                                  >>>
                                  >>
                                  >>
                                  >>
                                  > I've been around a while and these really are similar arguments that I
                                  > heard in the early days of widespread OO adoption. They are partly right
                                  > because you can really do bad work with misapplied tools and poor
                                  > understanding of them, plus a lack of "wisdom" about appropriate use.
                                  > With both OOP and AOP the flow of control is less obvious. So, it's
                                  > wrong to use either if the benefits don't justify the drawbacks.

                                  > I write
                                  > mostly procedural Perl code, appropriate for the problems I use it for,
                                  > but mostly OOP (and more lately, AOP) Java, as those projects have
                                  > scales that need the modularity tools OOP and AOP provide. The XP idea
                                  > of "doing the simplest thing that could possible work" has always been
                                  > important.

                                  I would have said the same thing a couple of years ago. I wrote a
                                  bunch of scripts that do file manipulation in Python, in fine procedural
                                  style. Then one day I decided to see what would happen if I started
                                  eliminating duplication. It worked nicely until I looked at a for statement
                                  and asked myself how I would eliminate that: every script had essentially
                                  the same for statement.

                                  What popped out was the visitor pattern. I still have the scripts,
                                  but they are now object oriented, and they are both shorter and
                                  clearer.

                                  > However, the arguments are partly wrong because, just as the issues with
                                  > OOP largely evaporated as better tools and understanding evolved, the
                                  > same thing will happen with AOP. Already, the tools for AspectJ,
                                  > especially in Eclipse, are quite good, and people are doing real work
                                  > with it. Learning to think in AOP terms is also essential, just as it
                                  > was/is for OOP.

                                  > In the early 90's, I saw some huge, well-publicized project failures
                                  > where teams inexperienced with OOP jumped in too quickly and failed
                                  > badly. I recall a project at Mentor Graphics that was widely discussed
                                  > in the trade press. Unfortunately, the hype peak of the adoption curve
                                  > of most technologies is hard to avoid, so I expect we'll see the same
                                  > problems as AOP catches on, followed by some backlash, followed by more
                                  > sober adoption and evolution.

                                  Wrestling any new technology to the ground and pinning it
                                  is difficult; I still see a few loose ends from the structured
                                  programming movement.

                                  > If you talk to these guys (and I've had the opportunity recently to do
                                  > that), they will tell you that they aren't adopting AOP because of the
                                  > hype curve; in fact most of their customers don't know what it is and
                                  > many don't yet seem very interested in it. Rather, the engineers at the
                                  > app. server vendors find AOP helps them address their own architecture
                                  > issues as they support the cross-cutting concerns we've listed already.
                                  > They've learned to downplay "selling" AOP itself and to just use it to
                                  > get real work done. That's the best approach, IMHO.

                                  The big difference here is that they're using it in the context of
                                  a single large application. In that context, it's simply another
                                  architectural pattern, and one that I can appreciate.

                                  More later on that point.

                                  >>The basic issue is very simple: if you layer a set of external
                                  >>hooks on top of a module, you are now putting dependencies
                                  >>in place that trust that the places you've hooked will stay stable.
                                  >>If they change, everything that has been layered on top of them
                                  >>will have to change.
                                  >>
                                  >>
                                  > This is a valid criticism of early implementations of AOP. It's received
                                  > a lot of recent attention in the field. It turns out that Java
                                  > annotations help a lot by decoupling meta information from actual names,
                                  > which are fragile. You then write your aspects to be coupled to the meta
                                  > information, instead, so they are resilent to name changes, etc. More
                                  > work is definitely needed, however.

                                  And that's really the crux of the entire issue. I think there's a lot
                                  of validity to the notion of assembling an application from parts.
                                  So have a lot of other people who are hopefully a lot wiser than
                                  I am. It's been a recurrant theme for a couple of decades at
                                  least; people have tried it and made incredible messes, see
                                  Microsoft Windows as the prototypical bad example here.

                                  I see it as basically a second dimension of layering.

                                  As an example, if I'm going to weave a typical matrix
                                  security approach into a typical task oriented transaction
                                  system, I need a lot more than simply the ability to insert
                                  methods into the underlying application. The underlying
                                  application needs to be, in some sense, conducive to
                                  having a security system layered on top of it, otherwise
                                  you're going to be going to a lot of trouble adjusting for
                                  inappropriate (from the security system's viewpoint)
                                  data and control flows.

                                  The truely interesting question in all of this is this:
                                  what kind of architecture is needed so that you can
                                  weave the various parts together smoothly?







                                  > Despite the issue we just discussed, "inserting code hooks in the right
                                  > places" is the essential problem AOP is solving.

                                  And it's the wrong question. The right question is: how do you
                                  get the "right places" so that the resulting system is comprehensible
                                  and mainainable?

                                  > Without diving into too
                                  > many details, if you look at a typical enterprise application code base,
                                  > the application logic tends to get lost in all the inserted boilerplate
                                  > for transactions, security, etc., etc.

                                  No question about that, although I suspect that a lot of the
                                  boilerplate is simply poor design.

                                  > AOP tries to extract this
                                  > boilerplate and restore true modularity. An analogy is hiding state and
                                  > behavior inside objects. You could insert it explicitly where you need
                                  > it, and as we discussed, sometimes that IS the best thing to do, but in
                                  > many cases you need the encapsulation.
                                  >
                                  > There's one important point about AOP that's worth clarifying. To use
                                  > the example of logging, yes a logging toolkit can be very modular and
                                  > your application code can be very modular. The cross-cutting concern
                                  > problem is that you have to sprinkle logging code all over your
                                  > application code. Add all the other cross-cutting concerns and then try
                                  > to make a strategic change to one of them and you get the cascading,
                                  > global code modifications that result from such "tangled" concern code.
                                  > AOP tries to solve this problem by pulling out the manually inserted
                                  > code and providing a way to succinctly define how to "weave" the aspects
                                  > into other code.

                                  Logging is, however, a very poor example simply because it's
                                  almost the poster child for AOP. Logging does not affect the state
                                  of the underlying application, and it usually doesn't matter very much
                                  how the underlying application is designed. In more realistic examples,
                                  neither statement is true. The layers interact and it is very important
                                  that the interactions occur at cleanly defined points.

                                  >>One arguement that I'm going to reject out of hand is
                                  >>the one that it addresses historically difficult problems.
                                  >>So does TDD, Simple Design and Refactoring. In other
                                  >>words, you're going to have to make a convincing argument
                                  >>that these _remain_ difficult problems when addressed
                                  >>by a team doing full bore TDD and agressive refactoring
                                  >>to remove duplication.

                                  > These are somewhat orthogonal tools. Would you argue that the best XP
                                  > practices eliminate the need for exploiting OOP and other modularity
                                  > design constructs? The same applies to AOP. It's another modularity tool
                                  > that complements OOP. The XP practices help you use both more
                                  > appropriately, etc., etc. If XP reduces the need for "fancy" design
                                  > tricks like AOP, OOP, patterns, etc., etc., then that's definitely a
                                  > good thing.

                                  Well, lets take a couple of realistic examples, security and
                                  persistance.

                                  We've discussed security a year or so ago on either this
                                  list or the newsgroup. The basic answer we came up with was
                                  that a typical matrix security approach concerned the boundaries
                                  of the system: the commands that a particular user was allowed
                                  to use, and the data that she was allowed to see.

                                  The command pattern centralizes this concern on the one
                                  end, and the Repository pattern (Evans, Domain Driven
                                  Design) centralizes it on the other. The remainder of the
                                  application can be unaware of security concerns.

                                  Persistance revolves around the very thorny issues of insuring
                                  that the various objects a transaction deals with are
                                  consistent when they're retrieved and when they're stored,
                                  and that they're in memory when needed. The solutions to
                                  this are the Aggragate and the Repository pattern, again from
                                  DDD.

                                  The point here is that it doesn't matter how well the crosscutting
                                  application (matrix security, persistance) is designed, if the
                                  underlying application isn't designed to work with it, then you
                                  have a major mess.

                                  If it is designed to work with it, there may well not be very much
                                  boilerplate code scattered around to get in the way.

                                  And this is the concern. AOP is a technology that doesn't
                                  address the very real architectural issues. It may force a discussion
                                  of those issues in a number of places, but the fact is that those
                                  same issues have been faced and resolved in successful systems
                                  for quite a while, and without a huge amount of boilerplate,
                                  fuss, muss, sturm and drang.

                                  John Roth
                                • Chris Wheeler
                                  ... exactly what this code does? And if not, what exactly does this code do? It looks interesting, but I haven t the faintest if I m interpreting it right.
                                  Message 16 of 23 , Apr 14, 2005
                                  • 0 Attachment
                                    On 4/14/05, Sean Gilbertson <sean_gilbertson@...> wrote:
                                    >
                                    >
                                    >
                                    > No, aspects are completely separate. You /can/ define them within classes
                                    > (as far as I understand), but I don't think that's typical. Here's an
                                    > example:
                                    >
                                    > /* Book.java */
                                    > public class Book {
                                    > private int allDone;
                                    >
                                    > public void read( ) {
                                    > /* .. */
                                    >
                                    > allDone = true;
                                    > }
                                    > }
                                    >
                                    > /* Library.java */
                                    > public aspect Library {
                                    > public pointcut reading( ) : call( void Book.read( ) );
                                    >
                                    > before( ) : reading( ) {
                                    > System.out.println( "done reading the book! please return it!" );
                                    > }
                                    > }
                                    >
                                    >
                                    > Would anyone think it completely thick of me to ask for an explanation of
                                    exactly what this code does? And if not, what exactly does this code do? It
                                    looks interesting, but I haven't the faintest if I'm interpreting it right.

                                    Chris.

                                    --
                                    ---------------------
                                    Chris Wheeler
                                    Extreme Programmer & Coach
                                    Visit my new site! http://www.agilelectric.com


                                    [Non-text portions of this message have been removed]
                                  • Dean Wampler
                                    You ve clearly thought more about this topic than I first assumed from your original post. Again, my bad. You brought up another big issues of active
                                    Message 17 of 23 , Apr 14, 2005
                                    • 0 Attachment
                                      You've clearly thought more about this topic than I first assumed from
                                      your original post. Again, my bad.

                                      You brought up another big issues of active investigation today (in
                                      addition to the previous issue concerning the potential for fragile
                                      coupling between aspects and the code they "advise"). This is the
                                      question of how to structure the coordination required between aspects
                                      and objects for nontrivial scenarios.

                                      If I can rephrase something you said, logging is a good "zeroth-order"
                                      example of AOP because it makes a great demo and it gets your attention,
                                      but it's really a "mixin" sort of thing; it has no affect on the state
                                      of the objects into which you insert logging, so the interaction is
                                      trivial. (It's also pretty safe to do, so it's a good, relatively-safe
                                      way to start using AOP tools today.)

                                      Security and persistence require nontrivial coordination with the
                                      modules they advice. A "good" AOP design is not so obvious. I think what
                                      will emerge are AOP patterns of collaboration, like OOP patterns, and
                                      also a lot of aspects will be written as glue (or implementations of the
                                      Bridge pattern) between modules we want to keep otherwise decoupled. The
                                      nontrivial logic will be handled in the AOP. Is this better than
                                      embedding the logic in the modules themselves? Time and individual
                                      circumstances will tell.

                                      Here's another security issue, from the "other end" (?); how do I
                                      prevent unwanted aspects from modifying my code? They could be viruses,
                                      performance killers, new code that hasn't been validated, etc.

                                      For awhile, people defined "obliviousness" as a key trait of AOP,
                                      meaning that an "advised" module is completely unaware of aspects that
                                      might advice it. Now, the more nuanced term "noninvasive" is preferred;
                                      an advisable module may be aware of the *possibility* of aspects and it
                                      may even expose interfaces tailored for collaboration with aspects, as
                                      well as restrictions on what can and can't be done with an aspect.
                                      However, it should still be possible to introduce actual aspects without
                                      modifying the module (otherwise, what's the point of it all ;^)

                                      So, I respect your skepticism, especially now that I understand it
                                      better ;^) You're absolutely correct that this is early-stage technology
                                      with some benefits today, but still in need of more work before it
                                      realizes its potential.

                                      Yours,
                                      dean

                                      yahoogroups@... wrote:
                                      > From: "Dean Wampler"
                                      > <dean.at.aspectprogramming.com@...>
                                      > To: "extremeprogramming@yahoogroups.com"
                                      > <extremeprogramming.at.yahoogroups.com@...>
                                      > Sent: Thursday, April 14, 2005 5:22 PM
                                      > Subject: Re: [XP] AOP
                                      >
                                      >
                                      >
                                      >>My intention was not to insult, just to offer a bit of levity (in the
                                      >>first paragraph) and a short answer for the benefit of all the other
                                      >>readers who may not be interested in a long discussion of a topic that
                                      >>is a bit off-topic (?). My apologies if you took offense. More below,
                                      >>since you asked....
                                      >
                                      >
                                      > OK.
                                      >
                                      >
                                      >>yahoogroups@... wrote:
                                      >>
                                      >>
                                      >>>>These are the same sorts of arguments that you heard in the early days
                                      >>>>of OOP. They are both right and wrong ;^)
                                      >>>>
                                      >>>>
                                      >>>
                                      >>>
                                      >>>
                                      >>I've been around a while and these really are similar arguments that I
                                      >>heard in the early days of widespread OO adoption. They are partly right
                                      >>because you can really do bad work with misapplied tools and poor
                                      >>understanding of them, plus a lack of "wisdom" about appropriate use.
                                      >>With both OOP and AOP the flow of control is less obvious. So, it's
                                      >>wrong to use either if the benefits don't justify the drawbacks.
                                      >
                                      >
                                      >>I write
                                      >>mostly procedural Perl code, appropriate for the problems I use it for,
                                      >>but mostly OOP (and more lately, AOP) Java, as those projects have
                                      >>scales that need the modularity tools OOP and AOP provide. The XP idea
                                      >>of "doing the simplest thing that could possible work" has always been
                                      >>important.
                                      >
                                      >
                                      > I would have said the same thing a couple of years ago. I wrote a
                                      > bunch of scripts that do file manipulation in Python, in fine procedural
                                      > style. Then one day I decided to see what would happen if I started
                                      > eliminating duplication. It worked nicely until I looked at a for statement
                                      > and asked myself how I would eliminate that: every script had essentially
                                      > the same for statement.
                                      >
                                      > What popped out was the visitor pattern. I still have the scripts,
                                      > but they are now object oriented, and they are both shorter and
                                      > clearer.
                                      >
                                      >
                                      >>However, the arguments are partly wrong because, just as the issues with
                                      >>OOP largely evaporated as better tools and understanding evolved, the
                                      >>same thing will happen with AOP. Already, the tools for AspectJ,
                                      >>especially in Eclipse, are quite good, and people are doing real work
                                      >>with it. Learning to think in AOP terms is also essential, just as it
                                      >>was/is for OOP.
                                      >
                                      >
                                      >>In the early 90's, I saw some huge, well-publicized project failures
                                      >>where teams inexperienced with OOP jumped in too quickly and failed
                                      >>badly. I recall a project at Mentor Graphics that was widely discussed
                                      >>in the trade press. Unfortunately, the hype peak of the adoption curve
                                      >>of most technologies is hard to avoid, so I expect we'll see the same
                                      >>problems as AOP catches on, followed by some backlash, followed by more
                                      >>sober adoption and evolution.
                                      >
                                      >
                                      > Wrestling any new technology to the ground and pinning it
                                      > is difficult; I still see a few loose ends from the structured
                                      > programming movement.
                                      >
                                      >
                                      >>If you talk to these guys (and I've had the opportunity recently to do
                                      >>that), they will tell you that they aren't adopting AOP because of the
                                      >>hype curve; in fact most of their customers don't know what it is and
                                      >>many don't yet seem very interested in it. Rather, the engineers at the
                                      >>app. server vendors find AOP helps them address their own architecture
                                      >>issues as they support the cross-cutting concerns we've listed already.
                                      >>They've learned to downplay "selling" AOP itself and to just use it to
                                      >>get real work done. That's the best approach, IMHO.
                                      >
                                      >
                                      > The big difference here is that they're using it in the context of
                                      > a single large application. In that context, it's simply another
                                      > architectural pattern, and one that I can appreciate.
                                      >
                                      > More later on that point.
                                      >
                                      >
                                      >>>The basic issue is very simple: if you layer a set of external
                                      >>>hooks on top of a module, you are now putting dependencies
                                      >>>in place that trust that the places you've hooked will stay stable.
                                      >>>If they change, everything that has been layered on top of them
                                      >>>will have to change.
                                      >>>
                                      >>>
                                      >>
                                      >>This is a valid criticism of early implementations of AOP. It's received
                                      >>a lot of recent attention in the field. It turns out that Java
                                      >>annotations help a lot by decoupling meta information from actual names,
                                      >>which are fragile. You then write your aspects to be coupled to the meta
                                      >>information, instead, so they are resilent to name changes, etc. More
                                      >>work is definitely needed, however.
                                      >
                                      >
                                      > And that's really the crux of the entire issue. I think there's a lot
                                      > of validity to the notion of assembling an application from parts.
                                      > So have a lot of other people who are hopefully a lot wiser than
                                      > I am. It's been a recurrant theme for a couple of decades at
                                      > least; people have tried it and made incredible messes, see
                                      > Microsoft Windows as the prototypical bad example here.
                                      >
                                      > I see it as basically a second dimension of layering.
                                      >
                                      > As an example, if I'm going to weave a typical matrix
                                      > security approach into a typical task oriented transaction
                                      > system, I need a lot more than simply the ability to insert
                                      > methods into the underlying application. The underlying
                                      > application needs to be, in some sense, conducive to
                                      > having a security system layered on top of it, otherwise
                                      > you're going to be going to a lot of trouble adjusting for
                                      > inappropriate (from the security system's viewpoint)
                                      > data and control flows.
                                      >
                                      > The truely interesting question in all of this is this:
                                      > what kind of architecture is needed so that you can
                                      > weave the various parts together smoothly?
                                      >
                                      >
                                      >
                                      >
                                      >
                                      >
                                      >
                                      >
                                      >>Despite the issue we just discussed, "inserting code hooks in the right
                                      >>places" is the essential problem AOP is solving.
                                      >
                                      >
                                      > And it's the wrong question. The right question is: how do you
                                      > get the "right places" so that the resulting system is comprehensible
                                      > and mainainable?
                                      >
                                      >
                                      >>Without diving into too
                                      >>many details, if you look at a typical enterprise application code base,
                                      >>the application logic tends to get lost in all the inserted boilerplate
                                      >>for transactions, security, etc., etc.
                                      >
                                      >
                                      > No question about that, although I suspect that a lot of the
                                      > boilerplate is simply poor design.
                                      >
                                      >
                                      >>AOP tries to extract this
                                      >>boilerplate and restore true modularity. An analogy is hiding state and
                                      >>behavior inside objects. You could insert it explicitly where you need
                                      >>it, and as we discussed, sometimes that IS the best thing to do, but in
                                      >>many cases you need the encapsulation.
                                      >>
                                      >>There's one important point about AOP that's worth clarifying. To use
                                      >>the example of logging, yes a logging toolkit can be very modular and
                                      >>your application code can be very modular. The cross-cutting concern
                                      >>problem is that you have to sprinkle logging code all over your
                                      >>application code. Add all the other cross-cutting concerns and then try
                                      >>to make a strategic change to one of them and you get the cascading,
                                      >>global code modifications that result from such "tangled" concern code.
                                      >>AOP tries to solve this problem by pulling out the manually inserted
                                      >>code and providing a way to succinctly define how to "weave" the aspects
                                      >>into other code.
                                      >
                                      >
                                      > Logging is, however, a very poor example simply because it's
                                      > almost the poster child for AOP. Logging does not affect the state
                                      > of the underlying application, and it usually doesn't matter very much
                                      > how the underlying application is designed. In more realistic examples,
                                      > neither statement is true. The layers interact and it is very important
                                      > that the interactions occur at cleanly defined points.
                                      >
                                      >
                                      >>>One arguement that I'm going to reject out of hand is
                                      >>>the one that it addresses historically difficult problems.
                                      >>>So does TDD, Simple Design and Refactoring. In other
                                      >>>words, you're going to have to make a convincing argument
                                      >>>that these _remain_ difficult problems when addressed
                                      >>>by a team doing full bore TDD and agressive refactoring
                                      >>>to remove duplication.
                                      >
                                      >
                                      >>These are somewhat orthogonal tools. Would you argue that the best XP
                                      >>practices eliminate the need for exploiting OOP and other modularity
                                      >>design constructs? The same applies to AOP. It's another modularity tool
                                      >>that complements OOP. The XP practices help you use both more
                                      >>appropriately, etc., etc. If XP reduces the need for "fancy" design
                                      >>tricks like AOP, OOP, patterns, etc., etc., then that's definitely a
                                      >>good thing.
                                      >
                                      >
                                      > Well, lets take a couple of realistic examples, security and
                                      > persistance.
                                      >
                                      > We've discussed security a year or so ago on either this
                                      > list or the newsgroup. The basic answer we came up with was
                                      > that a typical matrix security approach concerned the boundaries
                                      > of the system: the commands that a particular user was allowed
                                      > to use, and the data that she was allowed to see.
                                      >
                                      > The command pattern centralizes this concern on the one
                                      > end, and the Repository pattern (Evans, Domain Driven
                                      > Design) centralizes it on the other. The remainder of the
                                      > application can be unaware of security concerns.
                                      >
                                      > Persistance revolves around the very thorny issues of insuring
                                      > that the various objects a transaction deals with are
                                      > consistent when they're retrieved and when they're stored,
                                      > and that they're in memory when needed. The solutions to
                                      > this are the Aggragate and the Repository pattern, again from
                                      > DDD.
                                      >
                                      > The point here is that it doesn't matter how well the crosscutting
                                      > application (matrix security, persistance) is designed, if the
                                      > underlying application isn't designed to work with it, then you
                                      > have a major mess.
                                      >
                                      > If it is designed to work with it, there may well not be very much
                                      > boilerplate code scattered around to get in the way.
                                      >
                                      > And this is the concern. AOP is a technology that doesn't
                                      > address the very real architectural issues. It may force a discussion
                                      > of those issues in a number of places, but the fact is that those
                                      > same issues have been faced and resolved in successful systems
                                      > for quite a while, and without a huge amount of boilerplate,
                                      > fuss, muss, sturm and drang.
                                      >
                                      > John Roth
                                      >
                                      >
                                      >
                                      > To Post a message, send it to: extremeprogramming@...
                                      >
                                      > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                                      >
                                      > ad-free courtesy of objectmentor.com
                                      > Yahoo! Groups Links
                                      >
                                      >
                                      >
                                      >
                                      >
                                      >

                                      --
                                      Dean Wampler, Ph.D.
                                      dean at aspectprogramming.com
                                      http://www.aspectprogramming.com
                                      http://www.contract4j.org
                                      I want my tombstone to say:
                                      Unknown Application Error in Dean Wampler.exe.
                                      Application Terminated.
                                      [Okay] [Cancel]
                                    • Dean Wampler
                                      Welcome to AspectJ! ;^) I think the syntax takes a bit of getting used to. Here is a blow-by-blow description of the example: ... Plain Java, which should be
                                      Message 18 of 23 , Apr 14, 2005
                                      • 0 Attachment
                                        Welcome to AspectJ! ;^) I think the syntax takes a bit of getting used
                                        to. Here is a blow-by-blow description of the example:

                                        Chris Wheeler wrote:
                                        > On 4/14/05, Sean Gilbertson <sean_gilbertson@...> wrote:
                                        >
                                        >>
                                        >>
                                        >>No, aspects are completely separate. You /can/ define them within classes
                                        >>(as far as I understand), but I don't think that's typical. Here's an
                                        >>example:
                                        >>
                                        >>/* Book.java */

                                        Plain Java, which should be what you're used to...

                                        >>public class Book {
                                        >>private int allDone;
                                        >>
                                        >>public void read( ) {
                                        >>/* .. */
                                        >>
                                        >>allDone = true;
                                        >>}
                                        >>}
                                        >>

                                        Note that aspectj (AJ) also recognizes the ".aj" extension. You can use
                                        either.
                                        >>/* Library.java */

                                        An aspect is declared like a class. In AJ, aspects are "first-class"
                                        citizens
                                        like classes.
                                        >>public aspect Library {

                                        This is the most interesting bit; a "pointcut" is a set of "join points"
                                        (yes, this spelling of the two terms is the convention). A join point is
                                        a point in the execution of the code where new behavior could be
                                        inserted. Examples include a method call (the point just before passing
                                        control to the method - used in the example), method execution (the
                                        point just inside the function after the parameters have been
                                        initialized - has slightly different context, etc. than the call), when
                                        a variable is set or read, etc., etc. AJ defines keywords for many (but
                                        not all possible) types of join points.
                                        So, this example defines a pointcut named "reading" with one join point,
                                        the call to Book's "read" method that takes no arguments and returns
                                        void (as opposed to other read methods that might exist). Pointcut
                                        specifications support wildcard conventions (e.g., all public void
                                        methods in Book that take any number of arguments: "public void
                                        Book.*(..)"), conditionals, etc.
                                        >>public pointcut reading( ) : call( void Book.read( ) );
                                        >>

                                        So what should we do when we find a matching join point? We want to
                                        insert new behavior, called "advise" (like we're advising the join
                                        point). We can have the advice execute *before* the join point, *after*
                                        it, both before and after (called *around*) and also handle exceptions
                                        thrown, etc.
                                        Here, a "before advise" is defined for the pointcut "reading"; just
                                        before Book.read() is called, insert a print statement.
                                        >>before( ) : reading( ) {
                                        >>System.out.println( "done reading the book! please return it!" );
                                        >>}
                                        >>}
                                        >>
                                        >>
                                        > Would anyone think it completely thick of me to ask for an explanation of
                                        >
                                        > exactly what this code does? And if not, what exactly does this code do? It
                                        > looks interesting, but I haven't the faintest if I'm interpreting it right.
                                        >
                                        > Chris.
                                        >

                                        --
                                        Dean Wampler, Ph.D.
                                        dean at aspectprogramming.com
                                        http://www.aspectprogramming.com
                                        http://www.contract4j.org
                                        I want my tombstone to say:
                                        Unknown Application Error in Dean Wampler.exe.
                                        Application Terminated.
                                        [Okay] [Cancel]
                                      • Dave Rooney
                                        ... That s actually not as much of a joke as you may think! Our group had the great opportunity to have Colin Sampaleanu from the Spring project to ourselves
                                        Message 19 of 23 , Apr 15, 2005
                                        • 0 Attachment
                                          > -----Original Message-----
                                          > From: extremeprogramming@yahoogroups.com
                                          > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Jeff Grigg
                                          > Sent: Thursday, April 14, 2005 5:08 PM
                                          > To: extremeprogramming@yahoogroups.com
                                          > Subject: [XP] Re: AOP pros and cons
                                          >
                                          > >> --- From: "Sean Gilbertson"
                                          > >>> Have any of you used Aspect-Oriented Programming
                                          > >>> (AOP) in your projects?
                                          >
                                          > >>> What do you think about it?
                                          >
                                          > I've been using it recently. Primarily for testing. And primarily
                                          > for working around issues with 3rd party code that we could not
                                          > change.
                                          >
                                          > I think it shows a lot of promise. But successful application of
                                          > AOP seems to rely on a foundation of good object-oriented design and
                                          > strong coding standards. And this can be an issue in many
                                          > development organizations. ;->

                                          That's actually not as much of a joke as you may think! Our group had
                                          the great opportunity to have Colin Sampaleanu from the Spring project
                                          to ourselves for a week last November. Some of us learned a pile about
                                          IOC frameworks and a bit of AOP, and drooled at the prospect of what we
                                          could do with it.

                                          However, others were completely and utterly lost - they wouldn't know
                                          where to start when it came to working with something like that. Not
                                          surprisingly, these same people aren't very strong with OO concepts.
                                          The bottom line is that the team is constrained to a certain extent by
                                          the abilities of the team as a whole.

                                          If we were to start using Spring/Hibernate/AOP, our truck number would
                                          plummet. Right now, with straight Java/J2EE/Struts/etc., it's at a
                                          relatively comfortable number.

                                          Is that a good excuse _not_ to use it? Of course not. However, it's
                                          our reality. FWIW, we're likely going to just bite the bullet and use
                                          Spring's rich client framework to implement some new functionality this
                                          summer.

                                          Dave Rooney
                                          Mayford Technologies
                                          http://www.mayford.ca
                                        • Dean Wampler
                                          One of the promises of AOP is that, by decoupling concerns more successfully, you can have your AOP experts who get it work on aspects while every one else
                                          Message 20 of 23 , Apr 15, 2005
                                          • 0 Attachment
                                            One of the promises of AOP is that, by decoupling "concerns" more
                                            successfully, you can have your AOP experts who "get it" work on aspects
                                            while every one else works on the "regular" stuff. In fact, this
                                            arrangement is recommended in the early stages of an adoption strategy,
                                            rather than diving in head first and failing badly!

                                            dean

                                            Dave Rooney wrote:
                                            >>-----Original Message-----
                                            >> [snip...]
                                            >
                                            > However, others were completely and utterly lost - they wouldn't know
                                            > where to start when it came to working with something like that. Not
                                            > surprisingly, these same people aren't very strong with OO concepts.
                                            > The bottom line is that the team is constrained to a certain extent by
                                            > the abilities of the team as a whole.
                                            >
                                            > If we were to start using Spring/Hibernate/AOP, our truck number would
                                            > plummet. Right now, with straight Java/J2EE/Struts/etc., it's at a
                                            > relatively comfortable number.
                                            >
                                            > Is that a good excuse _not_ to use it? Of course not. However, it's
                                            > our reality. FWIW, we're likely going to just bite the bullet and use
                                            > Spring's rich client framework to implement some new functionality this
                                            > summer.
                                            >
                                            > Dave Rooney
                                            > Mayford Technologies
                                            > http://www.mayford.ca

                                            --
                                            Dean Wampler, Ph.D.
                                            dean at aspectprogramming.com
                                            http://www.aspectprogramming.com
                                            http://www.contract4j.org
                                            I want my tombstone to say:
                                            Unknown Application Error in Dean Wampler.exe.
                                            Application Terminated.
                                            [Okay] [Cancel]
                                          • Jeff Grigg
                                            ... An excellent question! ;- ... Every time the void read() method in the Book class is called is an event in the program flow that we re going to
                                            Message 21 of 23 , Apr 15, 2005
                                            • 0 Attachment
                                              > --- Chris Wheeler wrote:
                                              >> Would anyone think it completely thick of me to ask for
                                              >> an explanation of exactly what this code does? [...]

                                              An excellent question! ;->

                                              --- Dean Wampler <dean@a...> wrote:
                                              > Welcome to AspectJ! ;^) I think the syntax takes a bit
                                              > of getting used to. Here is a blow-by-blow description
                                              > of the example:

                                              >> --- Sean Gilbertson <sean_gilbertson@f...> wrote:
                                              >>>public class Book {
                                              >>> private int allDone;
                                              >>> public void read( ) { /* .. */ allDone = true; }
                                              >>>}

                                              >>>public aspect Library {

                                              >>> public pointcut reading( ) : call( void Book.read( ) );

                                              "Every time the 'void read()' method in the 'Book' class is called"
                                              is an event in the program flow that we're going to call "reading".

                                              >>>before( ) : reading( ) {
                                              >>> System.out.println( "done reading the book! please return
                                              it!" );
                                              >>>}}

                                              In other words...
                                              "/Before/ each and every call to /the Book's "reading()" method/, do
                                              this: Print "done reading the book...".


                                              Hmmmm....
                                              Maybe we should say
                                              after() : reading() { ... }
                                              ;->


                                              [See? Aspects can have bugs too! :-]
                                            • Sean Gilbertson
                                              ... hahaha, good spot! Oh, it should also be mentioned that you can pre-empt the code in join points (maybe just method executions?). You can then just call
                                              Message 22 of 23 , Apr 15, 2005
                                              • 0 Attachment
                                                > Hmmmm....
                                                > Maybe we should say
                                                > after() : reading() { ... }
                                                > ;->
                                                >
                                                >
                                                > [See? Aspects can have bugs too! :-]

                                                hahaha, good spot!

                                                Oh, it should also be mentioned that you can pre-empt the code in join points (maybe just method executions?). You can then just call the special advice method "proceed( )" to continue executing the target method. You would do this to, for example, enable multi-threading of an object (arguably an outside concern most or all of the time?):

                                                /* warning: don't try this at home.
                                                * You could hurt your brain */
                                                public aspect BookThreader {
                                                public pointcut reading( ) : call( void Book.read( ) );

                                                around( ) : reading( ) {
                                                Runnable thread = new Runnable( ) {
                                                public void run( ) {
                                                /* run the target code */
                                                proceed( );
                                                }
                                                };

                                                thread.start( );
                                                }
                                                }

                                                Please excuse me if there are bugs in that, but I hope you get the gist of it. Now to make this a bit cooler or more interesting: you can make this aspect and its pointcut abstract, but leave the "around" logic in place, and then you could make a concrete subaspect of it which specifies where threading should be enabled. More simply: you now have a drop-in method of multi-threading essentially any operation in your codebase.

                                                On Fri, Apr 15, 2005 at 01:04:39PM -0000, Jeff Grigg wrote:
                                                >
                                                >
                                                > > --- Chris Wheeler wrote:
                                                > >> Would anyone think it completely thick of me to ask for
                                                > >> an explanation of exactly what this code does? [...]
                                                >
                                                > An excellent question! ;->
                                                >
                                                > --- Dean Wampler <dean@a...> wrote:
                                                > > Welcome to AspectJ! ;^) I think the syntax takes a bit
                                                > > of getting used to. Here is a blow-by-blow description
                                                > > of the example:
                                                >
                                                > >> --- Sean Gilbertson <sean_gilbertson@f...> wrote:
                                                > >>>public class Book {
                                                > >>> private int allDone;
                                                > >>> public void read( ) { /* .. */ allDone = true; }
                                                > >>>}
                                                >
                                                > >>>public aspect Library {
                                                >
                                                > >>> public pointcut reading( ) : call( void Book.read( ) );
                                                >
                                                > "Every time the 'void read()' method in the 'Book' class is called"
                                                > is an event in the program flow that we're going to call "reading".
                                                >
                                                > >>>before( ) : reading( ) {
                                                > >>> System.out.println( "done reading the book! please return
                                                > it!" );
                                                > >>>}}
                                                >
                                                > In other words...
                                                > "/Before/ each and every call to /the Book's "reading()" method/, do
                                                > this: Print "done reading the book...".
                                                >
                                                >
                                                > Hmmmm....
                                                > Maybe we should say
                                                > after() : reading() { ... }
                                                > ;->
                                                >
                                                >
                                                > [See? Aspects can have bugs too! :-]
                                                >
                                                >
                                                >
                                                >
                                                >
                                                > To Post a message, send it to: extremeprogramming@...
                                                >
                                                > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                                                >
                                                > ad-free courtesy of objectmentor.com
                                                > Yahoo! Groups Links
                                                >
                                                >
                                                >
                                                >
                                                >
                                                >

                                                --
                                                Sean Gilbertson
                                                IT Systems/Software Developer
                                              • Kari Hoijarvi
                                                A few quotations from the past: I have never seen need for more that seven data types David Parnas heard this during his dissertation. Once your programming
                                                Message 23 of 23 , Apr 15, 2005
                                                • 0 Attachment
                                                  A few quotations from the past:

                                                  "I have never seen need for more that seven data types"

                                                  David Parnas heard this during his dissertation.

                                                  "Once your programming language supports strings etc.
                                                  natively, you don't need classes. C++ templates are
                                                  useful for collection classes, languages with good
                                                  built in support don't need them."

                                                  Common criticism of C++ in nineties.

                                                  "I don't need AOP, it is useful only ..."

                                                  People never need something they don't know. Once
                                                  they learn one reason to use it, the next will pop
                                                  up quickly.

                                                  back to AOP:

                                                  I'm nowadays dealing with a lot of scientific data.
                                                  It's read-only and slowly changing, so caching is
                                                  easy and efficient. Unfortunately the code is also
                                                  littered along the 30 or so classes for different
                                                  types of data. During time I wrote it, I found no
                                                  C# support for ascpects, not it might be the time
                                                  to introduce "widely littered code snippets into
                                                  an aspect" refactoring.

                                                  Kari
                                                Your message has been successfully submitted and would be delivered to recipients shortly.