Aspect Oriented Programming

[ar3492]

Hello, I'm a post-graduate student at the Open University in the
United Kingdom. I'm carrying out research into Aspect Oriented
Programming (AOP) to investigate the reasons why it has not been more
widely adopted by commercial software developers and would be grateful
if you could help by taking a couple of minutes to complete the
questionnaire below. I would very much appreciate a response, even if
you have not previously used AOP.

Thanks a lot for your help,

Andrew Rowe


INTRODUCTION
This survey is being conducted for the Open University in order to
investigate the barriers to the adoption of aspect oriented
programming (AOP) in commercial software development. AOP has been
created to solve the problem of crosscutting concerns in software
development and whilst used in academic research, has yet to make an
impact in commerce. The results of this research will be used to
evaluate AOP and in deciding the direction of future developments.

Please return your completed questionnaire to
(e-mail address removed)

SECTION 1 - PARTICIPANT INFORMATION
In this section, please type the letter of the option which most
closely matches your own.

1. Current employment position:
a. Academic
b. Software developer/programmer
c. Tead lead/manager
d. Other (please specify)
Your answer:

2. Have you previously heard of aspect oriented programming (AOP)?
a. Yes
b. No
Your answer:

If you answered Yes to Question 2, please continue to question 3.
If you answered No to Question 2, your questionnaire ends here -
thanks for your time!

3. How many years of practical experience in AOP do you have? __
a. None or < 1 year
b. 1-2
c. 2-4
d. > 4
Your answer:


SECTION 2 - BARRIERS TO THE ADOPTION OF ASPECT ORIENTED PROGRAMMING

1. Strongly agree
2. Agree
3. Neither agree or disagree
4. Disagree
5. Strongly disagree

Using the scale of 1-5 shown above, please select the extent to which
you believe the following are barriers to the adoption of aspect
oriented programming:

1. AOP is an immature technology.
Your answer:

2. Not many interesting aspects outside of logging or tracing.
Your answer:

3. Not many meaningful examples to demonstrate the advantages of AOP.
Your answer:

4. AOP is not an improvement over object oriented programming.
Your answer:

5. Aspect oriented programs are very complicated.
Your answer:

6. Aspect oriented programs are difficult to test.
Your answer:

7. Aspect oriented programs are difficult to maintain.
Your answer:

8. Aspect oriented programs are difficult to debug.
Your answer:

9. Aspect oriented programs perform slowly.
Your answer:

10. The syntax of aspect oriented programs (e.g. join points) is
difficult to understand.
Your answer:

11. It is difficult to understand the execution pattern of an aspect
oriented application.
Your answer:

12. AOP is not supported in my chosen development language.
Your answer:

13. AOP is not supported in my chosen software development environment/
IDE.
Your answer:

14. AOP tools are immature.
Your answer:

15. AOP has a steep learning curve/is difficult to learn.
Your answer:

16. I do not have enough time to learn AOP.
Your answer:

17. High costs of adopting AOP (training/processes etc)
Your answer:

18. No established AOP software development methodology.
Your answer:

19. Application design is more difficult in AOP than in OO or
procedural development.
Your answer:

20. Please list below any other barriers which have not been
identified above.
Your answer:



Thank you for your time!

Please return your completed questionnaire to
(e-mail address removed)

 

[Nicholas Paldino [.NET/C# MVP]]

Interesting that there is no mention of the ordering problem anywhere in
here. IMO, that's probably one of the biggest hurdles to AOP adoption.

 

[David Anton]

I remember reading about AOP in the late 90's, thinking that it would be
interesting to play with it when it was widely available. However, my chosen
development environment is Visual Studio (for various reasons), and AOP has
simply not made its way there yet - AOP isn't compelling enough for me to
switch development environments.
--
http://www.tangiblesoftwaresolutions.com
C++ to C#
C++ to VB
C++ to Java
Instant C#: VB to C#
Instant VB: C# to VB
Instant C++ VB Edition: VB to C++/CLI
Instant C++ C# Edition: C# to C++/CLI

 

[Chris Mullins [MVP - C#]]

I'm not so sure about that. Although I could be completly be out left field
here, I freely admit...

I think the biggest problem is that few (including me) really know with AOP
is. I have some ideas, I've read some articles and surfed the web a bit, but
a deep computer-science level of understanding? Hrm. Not really.

Certainly, there's not deep support for AOP throughout Visual Studio, but
there are lots of things that seem to fit the bill.

I do alot of work on Frameworks and Infrastructure, and frequently use
Aspects. For me, this is generally done with Metadata (aka: Custom
Attributes) and some static helper classes. The .Net Framework also seems to
have some support for at least commno Aspects.

In much of our code, classes and methods are decorated with aspects like:
[Traceable(TraceLevel=Verbost)], or
[PacketHandler(RequiredAuth = SASL)] or

Many of the App Blocks coming out of the Patters & Practices group fall
under the general (at least to me) category of Aspects.

With the ability now to write Context Bound objects, and the use of custom
attributes, there is quite a bit of AOP that can be done, although I tend
not to see too many people doing it...

 

[Arne Vajhøj]

I do alot of work on Frameworks and Infrastructure, and frequently use
Aspects. For me, this is generally done with Metadata (aka: Custom
Attributes) and some static helper classes. The .Net Framework also seems to
have some support for at least commno Aspects.

In much of our code, classes and methods are decorated with aspects like:
[Traceable(TraceLevel=Verbost)], or
[PacketHandler(RequiredAuth = SASL)] or

Many of the App Blocks coming out of the Patters & Practices group fall
under the general (at least to me) category of Aspects.

With the ability now to write Context Bound objects, and the use of custom
attributes, there is quite a bit of AOP that can be done, although I tend
not to see too many people doing it...

I like AspectDNG.

Arne

 

[Michael S]

Here is my 2 cents.

AOP was very cool in the late -90ies and early -00.
Notably until people started using it. =)

With code spreading around all over the place, applications using it on a
large scale, was a maintainance nightmare. Compare to a database that makes
heavy use of triggers, it is very hard to get a grasp on how such a system
works.

The only thing I hear about AOP nowadays is that it is very good for
logging. You can use it for logging. Did I mention that you can use it for
logging? AOP is great for logging. =)

Now we have log4net.dll. All the AOP we ever need...

- Michael Starberg

 

[Jon Skeet [C# MVP]]

The only thing I hear about AOP nowadays is that it is very good for
logging. You can use it for logging. Did I mention that you can use it for
logging? AOP is great for logging. =)

I hear about AOP being used for 3 things:

1) Logging
2) Transaction handling
3) Security

Not a lot beyond that, but I'm sure it *is* used for more than that.

Now we have log4net.dll. All the AOP we ever need...

No, that's just a logging implementation - it's not a simple way of
saying (outside the code) "log every method call into this object" etc.
They're two very different aspects of logging.

 

[AMRowe]

Thanks for your comments. I agree that AOP is not well supported by
the IDE and having used log4net myself, logging seems to be taken care
of elsewhere.

I welcome any other comments that you have.

Andrew

 

[Frans Bouma [C# MVP]]

Here is my 2 cents.

AOP was very cool in the late -90ies and early -00.
Notably until people started using it. =)

With code spreading around all over the place, applications using it
on a large scale, was a maintainance nightmare. Compare to a database
that makes heavy use of triggers, it is very hard to get a grasp on
how such a system works.

The only thing I hear about AOP nowadays is that it is very good for
logging. You can use it for logging. Did I mention that you can use
it for logging? AOP is great for logging. =)

Now we have log4net.dll. All the AOP we ever need...

Not true. AOP in principle is about a way to separate concerns. As
it's proven that there's always a dominant concern which leads the
separation process ('the tyranny of the dominant decomposition' ) you
inevitably run into the problem where you will have combinations of
concerns inside your code even though you force yourself to keep things
separated. Things like guard clauses, error handling, datastructure
allocation etc. etc. which actually cross-cut the concern of the code
they're placed with.

AOP is a way to achieve fine-grained separations over more than 1
dimension. This is a different way of writing software, and if it is
handled as normal code writing, then yes it leads to a big pile of
unmaintainable nightmare, where you look at a routine but you have no
idea what happens with it at runtime.

In general I think in those cases, AOP is overused. For example you
can build any routine with AOP from small snippets of code, but that's
not what AOP is all about. AOP is about injecting cross-cutting
concern-related code into your actual code. Think about guard clauses,
error handling, logging indeed, transactional awareness and the like,
things which are cross cutting the concern YOUR code is all about.

You can do a lot yourself btw. Take this example:
public void SomeMethod(List<T> someList, string foo)
{
// typical guard clauses
if(someList==null)
{
throw new ArgumentNullException("someList");
}
if(foo==null)
{
throw new ArgumentNullException("foo");
}

// actual code...
}

When you write your methods, you don't want to think about those guard
clauses, all you want is writing the actual code. So you can also write
a routine which handles this for you, then SomeMethod becomes: (.NET
3.5)

public void SomeMethod(List<T> someList, string foo)
{
CheckForNull(new List<object>(){someList, foo},
new List<string>(){"someList", "foo"});
// actual code
}

or something (just cooked this up, there are perhaps better ways to do
this)

Although it's a bit odd perhaps, it now does separate the guard
clause/exception handling concern from the actual code. How many people
do this? Not many.

With AOP, you could achieve the same thing, but with even less code,
namely you could get rid of the call to CheckForNull, and inject that
call, or the guard clauses directly, with AOP.

Though, I agree with you that this isn't 'free': without proper
tooling to get overview of what is injected where, this can get out of
hand, or at least can give the feeling you're not in control of the
code anymore. But I think that's true for many things which are
powerful, people just have to learn how to use them properly.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

 

[Jon Skeet [C# MVP]]

On Jan 18, 9:00 am, "Frans Bouma [C# MVP]"

Though, I agree with you that this isn't 'free': without proper
tooling to get overview of what is injected where, this can get out of
hand, or at least can give the feeling you're not in control of the
code anymore. But I think that's true for many things which are
powerful, people just have to learn how to use them properly.

A bit like LINQ and C# query expressions then?

Jon

 

[Jeroen Mostert]

You can do a lot yourself btw. Take this example:
public void SomeMethod(List<T> someList, string foo)
{
// typical guard clauses
if(someList==null)
{
throw new ArgumentNullException("someList");
}
if(foo==null)
{
throw new ArgumentNullException("foo");
}

// actual code...
}

When you write your methods, you don't want to think about those guard
clauses, all you want is writing the actual code. So you can also write
a routine which handles this for you, then SomeMethod becomes: (.NET
3.5)

public void SomeMethod(List<T> someList, string foo)
{
CheckForNull(new List<object>(){someList, foo},
new List<string>(){"someList", "foo"});
// actual code
}

or something (just cooked this up, there are perhaps better ways to do
this)

Yes, there are (for one thing, your "CheckForNull" method needs to have a
check itself on matching argument lists!) Here's my preferred way of doing
that:

internal static class Guards {
public static void ArgumentNotNull(object value, string name) {
if (value == null) throw new ArgumentNullException(name);
}
...
}

....

public void SomeMethod(List<T> someList, string foo) {
Guards.ArgumentNotNull(someList, "someList");
Guards.ArgumentNotNull(foo, "foo");
...
}

It saves typing, is a bit more readable, and gives me an opportunity for
reuse for compound checks (like checking whether an array plus offsets is
valid) and localized messages.

With AOP, you could achieve the same thing, but with even less code,
namely you could get rid of the call to CheckForNull, and inject that
call, or the guard clauses directly, with AOP.

But then there still has to be a marker for the AOP code to know when to
inject this check (certainly not all null arguments are an error), or if you
prefer a marker for when to omit this check (since most are). And of course
you do *not* want there to be any chance of the AOP injection failing to
run, because that breaks your code, even though it still looks the same.
Without language support for enforcing that, I'd feel uncomfortable. At
least here I know I have to do it all explicitly.

Some enforced AOP for this could be useful, if it could, say, do the whole
package including XML comments. Then I could just say "this argument must
not be null" and it would generate the appropriate <exception> comment and
the check. But I'd want a pretty airtight build process for that.

 

[Frans Bouma [C# MVP]]

On Jan 18, 9:00 am, "Frans Bouma [C# MVP]"

Though, I agree with you that this isn't 'free': without
proper tooling to get overview of what is injected where, this can
get out of hand, or at least can give the feeling you're not in
control of the code anymore. But I think that's true for many
things which are powerful, people just have to learn how to use
them properly.

A bit like LINQ and C# query expressions then?

I disagree

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------