AOP could be confusing?

[sim085]

Hi,

I am asking this since I am currently reading about AOP. For me it is quite fair, and understand the concept behind it. However I personaly detect a level of confusion (please correct me if I am wrong). In the example of the book, i found something as follows:

To know you have to order more books, we do a Throws advise, that when NoMoreBooksException is thrown, it calls the method orderBook(Book b)

Now in usual programming, I would have cought that exception, and done that the same rather then doing it using AOP. Which seems why AOP is there for, so that you do not have the ordering of books in the same class that is responsable for buying books.

However in the config file we then have to define this. Doesn't that mean we are moving some of the bussiness logic (what the application has to do) inside the config file?

As I said I am still new on the whole AOP subject. I have read on the other elements of AOP and am currently in the Introduction Interceptor. However the tought of having bussiness logic in a config file really wories me (at the moment) hope someone here can show this element in a different light.

thanks and regards,
sim085

[Colin Yates]

It is a very valid argument.

Essentially the "logic that implements a usecase" is no longer inside a single class, it is in a set of classes and the configuration that wires up those classes.

When using AOP in particular, the XML file is no longer just describing configuration; as you say, important business logic is there. Where as before there would be an explicit "try {} catch (...) { orderMoreBooks() }" it is now spread out via an "OrderMoreBooksAdvice" *and* the XML that applies that advice to that method.

I do not necessarily think that this is wrong; but it is a really critical point to share with co-developers. All the fundamental design principles are there, but rather than there being a aingle chunk of code that implements a function, the "implementation" is spread out across code and XML.

My colleague blogged about something similiar that we were working on: http://blogs.warwick.ac.uk/chrismay/...or_developers/

[Colin Yates]

(more thoughts...)

This is not the same argument as wiring up collaborators because there you have explicit interfaces which describe behaviour and all you are doing is selecting a particular implementation of that described interface. Failure to wire up will result in NPE at runtime. This scenario is very different because failure to wire up will still allow the operation to execute at run time, but the required behaviour (i.e. reordering books if there are no available books) will not be executed. It will silently fail.

The *only* place that states "reorder books when an exception is thrown" is in the configuration, in the place that wires up the ReorderBooksAdvice with the orderBooks method. In this regard, the configuration *is* implementing business functionality.

As I said, this is slightly different from the wiring up collaborators because the business functionality is explicitly defined by the interfaces. The configuration is "merely" wiring up.

Interesting....

[sim085]

Thanks for the quick reply

Well personally I have no problem in having certain logic in the config file. Mostly since from what I read I can generate this config file from meta data placed in the classes, which would help a lot (in my own opinion).

Something else (btw - I just finished the chapter on AOP) about Introduction Interceptor

Maybe I did not understand this section completly ...

However from what I read, I understand that you need to create a bean that extends DelegatingIntroductionInterceptor, and implements the interface that will add the extra functionality to the other beans (ex: SayHello).

So we have something like this:

public class SayHelloMixin
   extends DelegatingIntroductionInterceptor implements SayHello{

   public String getHelloGreeting() {
      return "Hello, how are you?";
   }
}

Now the other bean that will make use of this Mixin are for example the 'Welcome' bean, and therefor my wiring is something as follows:

<bean id="courseService"
	class="org.springframework.aop.framework.ProxyFactoryBean">

	<property name="target">
		<bean class"com.mypackage.Welcome"/>
	</property>

	<property name="proxyInterfaces">
		<value>com.package.mixin.SayHelloMixin</value>
	</property>
</bean>

(ps: I could have some elements wrong in the above code, since i am still not that used to do this :$, also excuse me for putting so much code, but finding it hard to explain my toughts

From how I understood the book, it seems that the Welcome bean does not need to implement the SayHello interface, since that is handeled by the ProxyFactoryBean. Is this right?

By colaborators, do you mean when you add more then one pointcut together? sorry I may have not arrived to that section yet :$

regards and thanks
sim085