title: Why Use Spring's Dependency Injection Over Regular Dependency Injection?
body: <p>I'm just learning Spring coming from a Java background. What I understand dependency injection to be is that
  you supply the objects it's dependencies, rather than the object initializing its own dependencies. For example:</p>
  <pre class="lang-java prettyprint-override"><code>/*
     MyObj depends on HashMap as a dependency.
   */
  public class MyObj {
    private HashMap hashmap;
  
    public MyObj() {
      this.hashmap = new HashMap();
    }
  }
  </code></pre>
  <p>Instead of doing that, you supply the <code>HashMap</code> through the constructor.</p>
  <pre class="lang-java prettyprint-override"><code>/*
     MyObj depeneds on HashMap as a dependency.
   */
  public class MyObj {
    private HashMap hashmap;
  
    public MyObj(HashMap hashmap) {
      this.hashmap = hashmap;
    }
  }
  </code></pre>
  <p>This is what I think dependency injection to be. But the way Spring does it is, in my opinion, more code
  and just messier. In Spring, you have to have this separate method</p>
  <pre class="lang-java prettyprint-override"><code>@Bean
  public HashMap hashmap() {
    return new HashMap();
  }
  </code></pre>
  <p>Then construct the <code>MyObj</code> object using <code>ApplicationContext.getBean(MyObj.class)</code>. However, I find many problems
  with this method. First of all, in a Swing app, this is how I would initialze the component ui tree maker:</p>
  <pre class="lang-java prettyprint-override"><code>public class ComponentUI {
    public ComponentUI(JFrame frame, JPanel panel, ...) {
      this.frame = frame;
      this.panel = panel;
      ...
    }
  }
  </code></pre>
  <p>There are going to be many many components in that constructor. This way, I can construct <code>ComponentUI</code> by
  doing <code>new ComponentUI(...)</code> and pass in the components. With Spring, however, I have to have a separate
  method for each one. That takes a lot of space and a lot of time to make each method. But the problem
  I find even worse is that if there are two <code>JPanel</code>'s in the constructor, then you have to create two
  separate objects that extend <code>JPanel</code>. Let me show you what I mean:</p>
  <pre class="lang-java prettyprint-override"><code>public class ComponentUI {
    public ComponentUI(..., JPanel panel1, JPanel panel2, ...) {
      ...
      this.panel1 = panel1;
      this.panel2 = panel2;
      ...
    }
  }
  </code></pre>
  <p>With Spring, I can't do this:</p>
  <pre class="lang-java prettyprint-override"><code>@Bean
  public JPanel panel1() {
    ...
  }
  
  @Bean
  public JPanel panel2() {
    ...
  }
  </code></pre>
  <p>or else there will be two methods returning the same object, so Spring doesn't know which one to use.
  Instead, I have to create my own objects that derive from <code>JPanel</code> then use that everywhere. In my
  Swing app, I have a whole folder of components that derive from other components.</p>
  <p>So with these inconveniences in mind, why would I use Spring's dependency injection over regular dependency
  injection, which is, constructing the object and supplying the objects.</p>