AOP and pattern design

[moo]

Currently I'm doing some basic reading about the "extension object" pattern.

This pattern involves a lot of technical stuff like castings from A to B, asking for extensions....

Proposal: Instead of doing all this manually, it may be done through AOP. Now, the task is to translate this concern into an AOP aspect.

Problem: I have no pratical AOP experience.

Can someone help me to understand how this pattern may be translated to AOP.



Extension object:

A concrete base class, Subject, provides mechanisms to dynamically
add and query for extensions. A given extension must be
downcast to its specific interface (SpecificExtension) for use. The
pattern as a whole amounts to defining a standard way to cross
cast from one interface reference to another.

The aspect-oriented alternative to extension objects is extension
aspects (Figure eight). This approach eliminates the need for client
cross casting from one extension (or base interface) to another by
directly injecting the implementation of a specific interface into a
class seen by a given set of clients. Besides removing the cross
casting from client code, this approach reduces the run-time
overhead of the cross cast and the design complexity as measured
in number of classes and methods. The core functionality is more
reusable since its extension mechanism is not predefined via
inheritance from Subject and dependence upon Extension.

Excerpt taken from
http://www.cs.ubc.ca/~kdvolder/Works...2-nordberg.pdf

Page 3/6


Thank you.

[jbetancourt]

Though I'm not a Spring expert and have only begun to use AOP via Spring, it seems the "Extension Pattern" (after a very quick look) is used all over the place in Spring.

The reference manual has good stuff to get you started:
http://www.springframework.org/docs/reference/aop.html

BTW, here is another AOP Pattern reference: http://www.cs.ubc.ca/~jan/AODPs/


--- Josef Betancourt

[moo]

String clazz = "com.moo.foo.bar"
AdapterA adaptA = SomeFactory.newInstance(AdapterA.class, clazz);
AdapterB adaptB = SomeFactory.newInstance(AdapterB.class, clazz);

Now consider the above code:

Suppose class "com.moo.foo.bar" implements two interfaces AdapterA and AdapterB and SomeFactory is a static Factory, trying to fullfill our expectations, which are:

1. SomeFactory has a build-in classloader that loads the specified class at runtime. (Assuming it to be in our classpath)

2. We want SomeFactory to create our Adapter objects without having to class cast manually.

3. The only information we want to pass, is the class name and the type of interface we expect.

4. SomeFactory should have only one newInstance method for any case, so we can add new interfaces easily, if our requirements have changed, without having to add a new newInstance for each type:

static Object newInstance(Class c, String clazz)

Can (Spring) AOP turn a generic return type like for instance "Object" into the demanded type at runtime?.


<dream>
The next enhancement could be:

String clazz = "com.moo.foo.bar"
AdapterA adaptA = SomeFactory.newInstance(clazz);
AdapterB adaptB = SomeFactory.newInstance(clazz);

Let AOP look at the demanded return type and it will cast dynamically from Object to AdapterA or AdapterB
</dream>

[jbetancourt]

Would Spring's BeanFactory be able to fulfill bullet point three?

Object getBean(String,Class): returns a bean, registered under the given name. The bean returned will be cast to the given Class. If the bean could not be cast, corresponding exceptions will be thrown (BeanNotOfRequiredTypeException). Furthermore, all rules of the getBean(String) method apply (see above)

It seems that it could. But this is not really AOP just an example of a Factory pattern. But, I'll step aside and let the experts answer.

[moo]

Would Spring's BeanFactory be able to fulfill bullet point three?

Object getBean(String,Class): returns a bean, registered under the given name. The bean returned will be cast to the given Class. If the bean could not be cast, corresponding exceptions will be thrown (BeanNotOfRequiredTypeException). Furthermore, all rules of the getBean(String) method apply (see above)

It seems that it could. But this is not really AOP just an example of a Factory pattern. But, I'll step aside and let the experts answer.

Thank you for posting the links, they are very helpfull!

It could, if your world remains static every single day 7/7 * 53

Object getBean(String,Class): returns a bean, registered under the given name

but problem is the highlighted word "registered". So we are not talking about runtime conditions.

*And* we are completly circumventing Spring Factories, because SomeFactory uses a selfmade classloader.

[oliverhutchison]

Why wrong with doing this?

AdapterA adaptA = (AdapterA) SomeFactory.newInstance(AdapterA.class, clazz);

As Java is strongly typed there's no way to avoid the cast.

[moo]

Why wrong with doing this?

AdapterA adaptA = (AdapterA) SomeFactory.newInstance(AdapterA.class, clazz);

As Java is strongly typed there's no way to avoid the cast.

No I don't want to avoid casts. I do want to understand how AOP can help to build the "extension object" pattern and do the technical concerns for me. Maybe you are correct and this misuses AOP. But first I want to understand if it can be done, then I decide if I use it

[katentim]

From figure 8:

An aspect-oriented extension to an existing class simply augments that class to directly or indirectly realize the desired specific interface, eliminating the run-time crosscasting mechanism of the Extension Object pattern.

You can introduce interfaces to classes (Ref. Manual Section 5.3.2.5. Introduction advice).

[moo]

The DelegatingIntroductionInterceptor is designed to delegate an introduction to an actual implementation of the introduced interface(s), concealing the use of interception to do so. The delegate can be set to any object using a constructor argument; the default delegate (when the no-arg constructor is used) is this. Thus in the example below, the delegate is the LockMixin subclass of DelegatingIntroductionInterceptor. Given a delegate (by default itself) a DelegatingIntroductionInterceptor instance looks for all interfaces implemented by the delegate (other than IntroductionInterceptor), and will support introductions against any of them

Now this is quite difficult to understand!

Let's start with the first sentence

The DelegatingIntroductionInterceptor is designed to delegate an introduction to an actual implementation of the introduced interface(s), concealing the use of interception to do so.

Ok, the situation is, I'm loading a class via Class.forName() from whom I know that it implements one or more given interfaces.
You may describe it as
<T> object = <T> Class.forName("com.moo.bar")
where T is either InterfaceA, InterfaceB,...

So, at this moment I'm not interested in introducing an interface, because I already know what interfaces the loaded object implements. I'm only looking for a possibility to advice the above expression to dynamically replace parameter <T> depending on which interface is requested.

The next step could be to introduce new interfaces paired with new behaviour, to extend the object's capabilties. But I was glad, if could understand only the first part.

[oliverhutchison]

<T> object = <T> Class.forName&#40;"com.moo.bar"&#41;

This makes no sence. The only types you can cast Class to are Class and Object. Do you mean?

<T> object = <T> Class.forName&#40;"com.moo.bar"&#41;.newInstance&#40;&#41;

So, at this moment I'm not interested in introducing an interface, because I already know what interfaces the loaded object implements. I'm only looking for a possibility to advice the above expression to dynamically replace parameter <T> depending on which interface is requested.

There is no way in Java to dynamically change a cast at runtime. Unless you use code generation or pure reflection you will *always* have to cast to the requied interface at some point. Can you please send through another explanation of what it is you are trying to do. I don't understand your examples so far.

Ollie