「Spring」Explaining Dependency Injection (DI) and IoC

public class Girl {
    private Bikini outfit; // each girl will have a bikini when going out
    public Girl() {
        outfit = new Bikini(); // When you create a girl, you give her a Bikini for example
    }
}

First of all, through this code, you'll notice that when you create a Girl, you'll create a Bikini with her. At this point, Bikini exists, meaning it's a dependency of Girl.

By initializing attributes like this, you unintentionally create a bottleneck in your program. For instance, what if the Girl wants to wear a Dress + T-shirt or nothing at all? Would you change the Bikini class to SkirtWithTshirt or Naked, huh?

Or more dangerously, what if the Bikini outfit is damaged? (The Bikini class code doesn't work?) It will directly affect the Girl.

The issue here lies in the principle:

"Classes should not depend on low-level inheritance but rather on Abstraction."

It might sound a bit complex. Now let's change the code like this:

      
// An interface for dressing up
public interface Outfit {
    public void wear();
}

// A low-level object, implementing Outfits
public class Bikini implements Outfit {
    public void wear() {
        System.out.println("Wearing Bikini");
    }
}

// Now, Girl only depends on Outfit. If you want to change her outfit, you just need to give Outfit a new instance.
public class Girl {
    private Outfit outfit;
    public Girl() {
        outfit = new Bikini();
    }
}

At this point, we've abstracted the Girl's attribute, but in reality, Girl is still tied to a single Bikini. So, to change clothes for the girl, what do you have to do?

You have to further modify the code like this:

      
public class Girl {
    private Outfit outfit;
    public Girl(Outfit anything) {
        this.outfit = anything; // Creating a girl with a customizable outfit
        // Not too much dependency at the time of initialization or code.
    }
}

public class Main {
    public static void main(String[] agrs) {
        Outfit bikini = new Bikini(); // Creating a Bikini object outside the object
        Girl britSpear = new Girl(bikini); // Dress her in it when creating her.
}

      
public static void main(String[] args) {
    Outfit bikini = new Bikini();
    Accessories gucci = new GucciAccessories();
    HairStyle hair = new KoreanHairStyle();
    Girl ngocTrinh = new Girl(bikini, gucci, hair);
}

If there were someone to do this for us, wouldn't it be great?

Now, assuming that we define all the dependencies in the Project beforehand, describe them, and put them in a repository, then hand them over to a framework to manage. Whenever any Class is initialized and needs a dependency, this framework will automatically find it in the repository and inject it into the object for us. Wouldn't that be more convenient?

That's it! That's exactly the principle of Inversion of Control (IoC) - controlling the flow of control within the application not by the application itself but by the underlying framework.

The code then only needs something like this to get an object:

      
@Override
public void run(String... args) throws Exception {
    Girl girl = context.getBean(Girl.class);
}