title: Use of getBean as opposed to method injection in Spring
body: <p>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.</p>
  
  <p>The app uses Spring for the glue and currently it switches screens using getBean():</p>
  
  <pre><code>//event handler for a specific button
  public void actionPerformed(Event e) {
      setScreen( (Screen) applicationContext.getBean("screen1"));
  }
  </code></pre>
  
  <p>"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!</p>
  
  <p>The problem is - after reading <a href="https://stackoverflow.com/questions/812415/why-is-springs-applicationcontext-getbean-considered-bad">this page</a> 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().</p>
  
  <p>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.</p>
  
  <p>Is getBean() and method injection the only options in my case or have I missed something? </p>
  
  <p>And if so, is getBean() really so bad?</p>