Use of getBean as opposed to method injection in Spring

Question

I have an application that has multiple screens and each screen is selected via a button. Each screen contains pretty heavy-weight components so it's important that only the activate screen is in memory - all others should be available for garbage collection.

The app uses Spring for the glue and currently it switches screens using getBean():

//event handler for a specific button
public void actionPerformed(Event e) {
    setScreen( (Screen) applicationContext.getBean("screen1"));
}

"screen1" is a prototype bean so a new instance of the screen is created when the button is pressed. Also, setScreen() is the only place where a reference to Screen is maintained in the app so the previously active screen will be available for garbage collection. I haven't tested this yet but I expect it will work fine - no rocket science here!

The problem is - after reading this page about why getBean() is considered bad - I'm wondering whether there is a more idiomatic way to acheive the same results while removing the dependency on getBean().

I have looked at method injection and it looks to me to introduce complexity with little benefit. It's another concept to learn, more magic, adds dependency on CGLIB, etc. If I really want to remove the dependency on Spring, I can just introduce an interface that exposes the getBean() method.

Is getBean() and method injection the only options in my case or have I missed something?

And if so, is getBean() really so bad?

Answer 1

Have you considered a factory approach?

public interface ComponentFactory<T> {
  T create();
}

public class ScreenFactory implements ComponentFactory<Screen> {
  @Override
  Screen create() { ... }
}

public class MyApp {
  private ComponentFactory<Screen> screen1;

  public void actionPerformed(Event e) {
    setScreen(screen1.create());
  }

  public void setScreen1(ComponentFactory<Screen> screen1) {
    this.screen1 = screen1;
  }

  private void setScreen(Screen screen) { ... }
}

combined with:

<bean id="screenFactory" class="com.myclass.ScreenFactory"/>

<bean id="myapp" class="...">
  <property name="screen1" ref="screenFactory"/>
</bean>

You can of course auto-wire the above.

The problem with what you're doing is that it both hardcodes the bean you're instantiating and ties your implementation to ApplicationContext. If you ever need to mock and/or unit test your apps/components, then that'll make your life incredibly difficult. The factory solution above will make it trivial.

Answer 2

Setter injection, property injection or constructor injection all create a loosely coupled application that is much easier to test through mocking. It also prevents any of your classes from having direct dependencies on Spring (or other IoC container) classes. It ends up just being a cleaner overall solution when you don't have to manually call getBean().

I think you should become comfortable with the notion of configuring dependencies. The "magic" is not really magic at all and is just something that you will become comfortable with as you use it.

Answer 3

If you just want to get rid of the getBean, consider using a ServiceLocatorFactoryBean. But how well this works for you may depend on where the string "screen1" is coming from in your application.