The latest versions of Spring introduce two new types of method injection: lookup methods and method replacement. Craig Walls has used this ability to wire up a bean which inherits one method from one class, and one from another.

Here we see the wiring up of the methods:

<beans>
  <bean id="recorder" class="com.habuma.wiring.AbstractRecorder">
    <replaced-method name="record" replacer="recordDevice"/>
    <replaced-method name="playback" replacer="playbackDevice"/>
  </bean>
      
  <bean id="recordDevice"
      class="com.habuma.wiring.TapeRecorder"/>
  <bean id="playbackDevice"
      class="com.habuma.wiring.SpeakerPlayback"/>
</beans>

This smells of pseudo-multiple inheritance. What do you think?

It's not terribly hard to create a plain Java approach that'll do this, particularly with the Annotations in 1.5

But so what?

If you don't mind tangling with multiple inheritance, risking the diamond inheritance pattern and all that entails, more fool you. But I can't see any reason why you shouldn't if you really want to.

The latest version of Spring may make it easier to do this, but my guess is that if you're sophisticated enough to be using Spring in the first place, you're probably old enough to make your own decisions and understand the implications.

Anyone who's blithe enough to do it by mistake has more fundamental things to worry about.

Dave.

I think that the more of these thing that is possible, the less OO the code will become. So what?, you say, but when it comes to maintain code of others it matters a lot.

I think dependency injection (or IOC) should be used solely for constructors. This makes it impossible to create objects of the class in other ways without having to know what setters that should be called in advance. This also means that classes could be reused and they are easier to maintain.

Say you have to maintain code written by others, but you have to refer to xml-files to see what code is actually run. The problem is the same with AOP, but there you will at least have the tool support (which is crucial to its success).

For more information, see Craig's blog entry. I'm not too sure whether the extra complexity is worth it. We've been using Spring extensively and we haven't found a need to arbitrarily replace methods. Also, you can achieve the same thing using Spring AOP. I guess I'd like to understand the particular itch that this scratches a little better.

I guess I'd like to understand the particular itch that this scratches a little better.

And that's precisely my reason for writing that blog entry in the first place. I wanted to ask what method replacement is good for. As I wrote it, I started seeing a possible usage scenario and described it. But as others have pointed out, it's not necessarily the best idea (I don't disagree).

So...I'm left with my original question: What good is method replacement? What itch does it scratch? If this is my hammer, what does a nail look like?

Also, you can achieve the same thing using Spring AOP. I guess I'd like to understand the particular itch that this scratches a little better.

Yes, you can implement similar things using AOP introductions. Maybe this could be used to introduce new interfaces to classes as Mixins. Using replaced-methods in beans.xml is a bit simpler than defining the proxy etc. that are required by the AOP approach.

Looks like this could be used to implement Richard Öberg's "abstract schema" concept (http://www.theserverside.com/news/thread.tss?thread_id=29312#142634). I'm don't know if this is intended for that purpose though.

Of course you don't have type safety in these method replacer classes...

Looks like this could be used to implement Richard Öberg's "abstract schema" concept

Spring 1.2 will include support for Ricard's "abstract schema" concept, in the AOP framework.

This smells of pseudo-multiple inheritance. What do you think?

I think it smells bad. MI support is, for me, out of the question unless it is as well supported as in Eiffel (in which derived method renaming etc. is allowed.)

In the 0.1% design situations where MI would be useful there are always workarounds.

A hack like this is not worth the added complexity.

IMNSHO.

I think Spring is great, but I'm hesitant to do anything that I can't instantiate myself put into a simple test case.

I think it would make more sense to write a new object and delegate behavior via an object previously set. Eclipse has a two click wizard for delegating methods that aren't reflection based (performance saver).

I agree. I think it's great that Craig is exploring this capability, but I'm hesitant to put too much wiring into the applicationContext.xml file, i.e. particularly if it changes method names.

IMO, this is most useful only if you want to do delegation (inheritance by delegation or composition by delegation). Yet, the same can be done with the standards IoC tools. So... is this totally worthless? Or am I being short-sigthed?

If I were you, I would first try to see what are the real live cases for such thing...

If there are not so many (close to ZERO) than I would not implement it into framework...since it can bloat it with the functionality that rarely used...(will be similar to now bloated STRUTS)

In general, frameworks should be kept on "diet" to be slim, light and performing well.

Just my 2 cents.

If I were you, I would first try to see what are the real live cases for such thing...If there are not so many (close to ZERO) than I would not implement it into framework...since it can bloat it with the functionality that rarely used...(will be similar to now bloated STRUTS)In general, frameworks should be kept on "diet" to be slim, light and performing well.Just my 2 cents.

I agree. I certainly hope Spring won't become a Babilonia of features that 'might' be usefull, just like so many others. Until now Spring has been very focused and each thing in it has a clear destination, everything had a clear aim. That's what made Spring popular. It fulfilled developer's needs in a much simpler way than any other alternative enforcing/making possible best practices usage.

On the other hand open source drives inovation so you can't stop things from evolving. And you shouldn't. Still, I will have to see who benefits from method replacenment though :-)

Still, I will have to see who benefits from method replacenment though :-)

The original motivation for this whole area of functionality was "lookup methods", which have a compelling use case when you want to avoid the need to implement a Spring interface such as BeanFactoryAware to be able to create multiple independent instances of a single-threaded helper. This satisfied I real need I had in a project at the time, and I usually find one or two very useful cases for this in any large application. I hate depending on Spring APIs.

I included the more generic Method Replacement feature because it was virtually free given the implementation of Lookup Methods. It's certainly a rarer usage, but it adds practically no further complexity to Spring's implementation.

Rgds
Rod

Some MI motivations info can be found from Rod's blog:
http://blog.springframework.com/rod/index.php?m=200408

Rod wrote:
"I love working with Spring, but I hate having to import Spring APIs for configuration".

Just my 0.02

José.

Some MI motivations info can be found from Rod's blog:http://blog.springframework.com/rod/index.php?m=200408Rod wrote:"I love working with Spring, but I hate having to import Spring APIs for configuration".Just my 0.02José.

I really like what they are describing, I don't think I'm going to choose spring anytime soon. The most enlightening bits I've ever read are from www.alexwinston.com where he talks about the Abstract models using CGLIB and PicoContainer (constructor injection). I don't want to sound like I'm contradicting my original post, but I simply want to be able to do the same thing the container does without too much programming and without API dependencies-- Alex Winston's posts on IoC are just that.

Rod Johnson:

I hate depending on Spring APIs.

Now, really, this is a bit hysterical… Why taking it to another extreme like that?

Regards,
Nikita.

Rod:
I hate depending on Spring APIs.

Well, in the spirit of dynamically renaming class methods, I would like to propose another feature to Spring team: Let's have a way to rename Java null to nil.

I love using Java, but I hate depending on it.

:-)

--Dmitriy.

I hate depending on Spring APIs.

To clarify, one of the many benefits of Dependency Injection is maximizing potential for reuse. Hence it's best to avoid depending on any framework API (Spring or other) for configuration management if there's a good alternative. For example, if there's a good option that allows running without any container (e.g. in a JUnit test case) it's worth considering. A good IoC container should give you that choice.

Rod Johnson:
Hence it's best to avoid depending on any framework API (Spring or other) for configuration management if there's a good alternative.

The bottom line is that whether or not you conform to some Spring API when you use Spring, your code still depends on Spring. You cannot blindly move it to, let’s say, Jboss or Pico. There is nothing to fix here, and, by all means, you should not try to fix it by introducing such a huge hack as dynamically renaming Java class methods at runtime to adhere to Spring APIs behind the scenes.

It is a definite design smell in my book.

Regards,
--Dmitriy.

by introducing such a huge hack as dynamically renaming Java class methods at runtime to adhere to Spring APIs behind the scenes

Spring contains no functionality intended to "dynamically rename Java class methods at runtime to adhere to Spring APIs behind the scenes." It's possible to override methods, and appropriate in a small number of cases. I've explained the reasons for doing so, in this thread and on my blog, and they are not specific to Spring. "Renaming" methods is not something Spring offers. There is no "huge hack" here: only a feature that addresses a corner case, which adds perhaps 2K to the size of spring.jar and which no one is forced to use.

Let me chip in…
I would actually agree with Rod that there is no specific renaming functionality in Spring per-se. It is really about XML-ed configuration of dynamic proxies.

But I would echo the previous comments that this is rather clear example of “reverse designing”: while working on AOP Spring team came across interesting and cool side effect, namely, that they can XML-ed dynamic proxy configuration. Once that was in they have “made up” couple of “corner” use cases.

It reminds me very much of complex regex-based or cflow pointcuts in AspectJ, where solution ultimately creates bigger design problem than the one it is trying to solve.

Regards,
Nikita.

Hi,

But I would echo the previous comments that this is rather clear example of “reverse designing”: while working on AOP Spring team came across interesting and cool side effect, namely, that they can XML-ed dynamic proxy configuration.

I think it's been clearly stated when the feauture should be used (i.e. almost never; there IS a case however). And Rod also affirmed that this indeed was a cool side effect at no cost. So I don't see a problem here. Just don't use it. Absurd comes in when a feature is used at a wrong place.

I'm just curious (out of pure interest) whether method lookup is implemented with method replacement under the hood (i.e. with a prebuilt Reimplementor).

al

I'm just curious (out of pure interest) whether method lookup is implemented with method replacement under the hood (i.e. with a prebuilt Reimplementor).

There's a common base class for the objects representing the two kinds of replacement, but they don't use the same class.

Rod Johnson:
Hence it's best to avoid depending on any framework API (Spring or other) for configuration management if there's a good alternative.

The bottom line is that whether or not you conform to some Spring API when you use Spring, your code still depends on Spring. You cannot blindly move it to, let’s say, Jboss or Pico. There is nothing to fix here, and, by all means, you should not try to fix it by introducing such a huge hack as dynamically renaming Java class methods at runtime to adhere to Spring APIs behind the scenes.

It is a definite design smell in my book.

Regards,
--Dmitriy.