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

Aspect Oriented Programming and XP

Expand Messages
  • Paul Hodgetts
    I was reading an article in the latest JOOP about class extensions a la ENVY, and how it was like Aspect Oriented Programming (AOP). It got me thinking about
    Message 1 of 7 , Dec 30, 2000
    • 0 Attachment
      I was reading an article in the latest JOOP about class extensions
      a la ENVY, and how it was like Aspect Oriented Programming (AOP).
      It got me thinking about whether there was anything AOP could offer
      in the XP context.

      Does anyone have experience with ENVY or AOP, perhaps on an XP
      project?

      Since AOP aims to separate out the different aspects of a class's
      responsibilities, it seems like it could help avoid collisions
      when multiple pairs are rapidly modifying and integrating code.
      It also seems like an additional technique for removing
      duplication, especially since it addresses code that may not be
      able to be refactored out using "traditional" techniques.

      For example, if aspects of persistence, security, and logging are
      kept in separate packages and source files, and then woven (an AOP
      term) into the main domain classes at compile time, then a pair
      could be off modifying the security aspect with out crashing into
      a pair modifying the main domain class.

      The down sides that I see are that AOP currently is implemented
      (in Java) with a preprocessor. That adds an extra step into the
      build cycle, which could make for a longer code/build/test round
      trip. It also adds some additional language constructs, which in
      turn makes the code more complex. There is a learning curve
      involved as well (which is where I'm at right now in playing
      around with AOP).

      Thoughts? Has anyone worked with the Smalltalk ENVY environment?

      -Paul Hodgetts
    • John Brewer
      ... AOP looks real cool, but I have code to ship today. I only just last month got to use Sun s Java collection classes. I have Generic Java down as a todo
      Message 2 of 7 , Dec 30, 2000
      • 0 Attachment
        --- In extremeprogramming@egroups.com, Paul Hodgetts <prh@z...> wrote:
        > Does anyone have experience with ENVY or AOP, perhaps on an XP
        > project?

        AOP looks real cool, but I have code to ship today. I only just
        last month got to use Sun's Java collection classes. I have Generic
        Java down as a todo sometime in 2002, and AspectJ in 2005.

        John Brewer
        Jera Design
      • Phlip
        ... Mightn t someone think of a scenario where this AOP thing, and nothing else, would be the best fix for a nasty violation of OAOO? --Phlip
        Message 3 of 7 , Dec 30, 2000
        • 0 Attachment
          "John Brewer" <jbrewer@j...> wrote:

          > AOP looks real cool, but I have code to ship today. I only just
          > last month got to use Sun's Java collection classes. I have Generic
          > Java down as a todo sometime in 2002, and AspectJ in 2005.

          Mightn't someone think of a scenario where this AOP thing, and nothing
          else, would be the best fix for a nasty violation of OAOO?

          --Phlip
        • Paul Hodgetts
          ... Hmmm... If I m reading between the lines... You have no current issue that leads you to seek a solution like GJ or AOP. And only recently had an issue
          Message 4 of 7 , Dec 30, 2000
          • 0 Attachment
            John Brewer wrote:

            > AOP looks real cool, but I have code to ship today. I only just
            > last month got to use Sun's Java collection classes. I have Generic
            > Java down as a todo sometime in 2002, and AspectJ in 2005.

            Hmmm... If I'm reading between the lines...

            You have no current issue that leads you to seek a solution like
            GJ or AOP. And only recently had an issue that led you to use
            the collection classes. R&D without an immediate need is
            anticipatory.

            Am I close?

            -Paul Hodgetts
          • John Brewer
            ... Close. All of these technologies would make my job easier. But I have to weigh that against the risk of using a non-mainstream technology. In the case
            Message 5 of 7 , Dec 31, 2000
            • 0 Attachment
              --- In extremeprogramming@egroups.com, Paul Hodgetts <prh@z...> wrote:
              > Hmmm... If I'm reading between the lines...
              >
              > You have no current issue that leads you to seek a solution like
              > GJ or AOP. And only recently had an issue that led you to use
              > the collection classes. R&D without an immediate need is
              > anticipatory.
              >
              > Am I close?

              Close. All of these technologies would make my job easier. But I
              have to weigh that against the risk of using a non-mainstream
              technology. In the case of collections, it's only been with my latest
              client that I've been able to use Java 2.

              You can do XP fine without the latest, shiniest technology. That
              doesn't mean you shouldn't be on the lookout for new stuff -- just be
              aware of the risks as well as the benefits.

              John Brewer
              Jera Design
            • Jeff McKenna
              AOP is very interesting. See the book Working with Objects by Treygve Reenskaug for an in-depth treatment. Your comments regarding XP and AOP seem correct
              Message 6 of 7 , Dec 31, 2000
              • 0 Attachment
                AOP is very interesting. See the book "Working with Objects" by
                Treygve Reenskaug for an in-depth treatment.

                Your comments regarding XP and AOP seem correct to me. My take, which
                was confirmed by the developers of Aspect/J at OOPSLA, is that you do
                not want to develop your 'whole' application using aspects. They then
                form a kind of loosly coupled set of hierarchies thus giving more than
                the usual headaches and confusion of multiple inhieritance with little
                language support for error resolution. But when used precisely, as
                your examples suggest, they can be powerful for keeping distinct
                things distinct.

                Another possibility with AOP is to use it to spike. One could make
                hooks into existing code without changing the code. Spikes could then
                more easily be used over time without the normal problem of a spike
                being a branch and thus dependent on the main code at the time of
                spike.

                I have used ENVY extensively. I have not read the JOOP article. What
                exactly is your question?


                --- In extremeprogramming@egroups.com, Paul Hodgetts <prh@z...> wrote:
                > I was reading an article in the latest JOOP about class extensions
                > a la ENVY, and how it was like Aspect Oriented Programming (AOP).
                > It got me thinking about whether there was anything AOP could offer
                > in the XP context.
                >
                > Does anyone have experience with ENVY or AOP, perhaps on an XP
                > project?
                >
                > Since AOP aims to separate out the different aspects of a class's
                > responsibilities, it seems like it could help avoid collisions
                > when multiple pairs are rapidly modifying and integrating code.
                > It also seems like an additional technique for removing
                > duplication, especially since it addresses code that may not be
                > able to be refactored out using "traditional" techniques.
                >
                > For example, if aspects of persistence, security, and logging are
                > kept in separate packages and source files, and then woven (an AOP
                > term) into the main domain classes at compile time, then a pair
                > could be off modifying the security aspect with out crashing into
                > a pair modifying the main domain class.
                >
                > The down sides that I see are that AOP currently is implemented
                > (in Java) with a preprocessor. That adds an extra step into the
                > build cycle, which could make for a longer code/build/test round
                > trip. It also adds some additional language constructs, which in
                > turn makes the code more complex. There is a learning curve
                > involved as well (which is where I'm at right now in playing
                > around with AOP).
                >
                > Thoughts? Has anyone worked with the Smalltalk ENVY environment?
                >
                > -Paul Hodgetts
              • Paul Hodgetts
                ... I have not used ENVY at all (and barely touched Smalltalk). ENVY seems like a configuration control environment that supports, among other things, AOP
                Message 7 of 7 , Jan 1, 2001
                • 0 Attachment
                  Jeff McKenna wrote:

                  > I have used ENVY extensively. I have not read the JOOP article. What
                  > exactly is your question?

                  I have not used ENVY at all (and barely touched Smalltalk). ENVY
                  seems like a configuration control environment that supports, among
                  other things, AOP with built in features for maintaining the aspects
                  (extensions) and weaving them together. Is this accurate?

                  When using the AOP-like features of ENVY, do they provide any
                  additional support and benefit to the XP practices? Specifically,
                  does using aspects help with continuous integration by reducing
                  collisions and merges from parallel code changes? If so, are the
                  benefits worth the additional cost and complexity of the feature?

                  Thanks for your (and everyone else's) comments!

                  -Paul Hodgetts
                Your message has been successfully submitted and would be delivered to recipients shortly.