🌱Spring IoC and DI

Spring IoC (Inversion of Control)

객체의 관리를 스프링 컨테이너(혹은 IoC 컨테이너)에 맡겨 제어권이 넘어간 것을 의미한다.

=> 스프링을 사용하면 객체의 제어권을 컨테이너로 넘기기 때문에 개발자는 비즈니스 로직 작성만 집중하면 된다.

결론적으로 제어의 역전을 통해 의존성 주입(DI), 관점 지향 프로그래밍(AOP)등이 가능해진다.

---

DI 컨테이너🤵

의존성 주입(Dependency Injection) 줄여서 DI의 실현을 돕는 프레임워크를 의미한다.

의존성🫱🏼‍🫲🏻

Ex)
사용하는 객체 : A클래스, 사용되는 객체 : B클래스

A클래스에서 B클래스를 사용하려면 new 키워드를 사용하여 B클래스의 인스턴스를 만들고 B 클래스의 메서드를 사용하게 된다.

이때, B클래스에서 구현했던 메서드를 변경하면 A클래스에서도 해당 메서드를 변경해야한다.
이런 관계를 "A클래스는 B클래스에 의존한다"라고 한다.

---

의존의 유형🤔

• 클래스의 의존(구현 의존)
• 인터페이스 의존

📌클래스의 의존

'사용하는 객체' A클래스에서 '사용되는 객체'인 B클래스의 methodX 메서드를 호출하는 경우를 예로 들어보겠다!

//클래스 의존에서 인스턴스 생성과 메서드 호출
//현재코드에서는  A클래스에서 new 키워드를 사용하여 B클래스의 인스턴스를 생성한다.
//인스턴스에서 methodX() 메서드를 호출한다.
class A{
	public 반환형 메서드1(){
      B b = new B();
      b.methodX();
    }
}
class B{
	public methodX(){
    	...
    }
}

해당 코드를 사용하는 도중 설계가 변경되어서 '사용되는 객체'를 새롭게 생선된 C클래스로 변경하고 methodY()메서드를 호출하도록 변경한다.

//클래스 의존에서 인스턴스 생성과 메서드 호출
//현재코드에서는  A클래스에서 new 키워드를 사용하여 B클래스의 인스턴스를 생성한다.
//인스턴스에서 methodX() 메서드를 호출한다.
class A{
	public 반환형 메서드1(){
      B b = new B();
      b.methodX();
    }
}
class B{
	public methodX(){
    	...
    }
}
class C{
	public methodY(){
    	...
    }
}

이러한 상황에서 어떻게 A클래스의 메서드1() 메서드를 수정하는지 생각하면 다음 코드와 같이 변경하려고 생각할 것이다.

//클래스 의존에서 '사용하는 객체'클래스의 세 군데를 수정
class A{
	public 반환형 메서드1(){
      C c = new C(); //C->B변경, B() -> C() 변경
      c.methodY(); //변경
    }
}

• A클래스를 세 군데 수정하였다. 이처럼 사용하는 객체 클래스에서 사용되는 객체 클래스의 타입을 직접 지정해 버리면 '사용되는 객체' 클래스를 변경할 경우 이를 이용하고 있는 곳을 모두 수정해야 한다.
• 이렇게 되면 수정한 부분이 늘어나게 될 경우 실수가 발생할 위험이 높아진다.
• 또한, 수정할 곳이 10군데, 100군데, 1000군데에 있을 경우 수정 작업과 수정에 의한 동작을 테스트하는데 걸리는 시간이 기하급수적으로 늘어날 것이다.

---

📌인터페이스 의존

Ex)
I인터페이스가 있고 이것을 구현한 '사용되는 객체'인 B 클래스가 있다. '사용하는 객체'인 A클래스에서 B클래스의 methodX 메서드를 호출한다.


1. A클래스에서 new 키워드를 사용하여 B클래스의 인스턴스를 생성한다.
2. 인스턴스에서 methodX 메서드를 호출한다.


여기서 주의해야할 점은 A클래스에서는 인터페이스로 추상화된 I를 이용한다는 것이다.

//인터페이스에 의존하는 인스턴스의 생성 및 메서드 호출
class A{
	public 반환형 메서드1(){
      I i = new B(); 
      i.methodX();
    }
}

interface I{
	methodX();
}

class B implements I{
	methodX(){
    	...
    }
}

이번에도 설계가 변경되어서 '사용되는 객체'클래스를 변경하게 됐다고 가정하게 되면 '사용되는 객체' C클래스(I인터페이스를 구현)를 호출해 methodX메서드를 호출하도록 변경한다.

//인터페이스에 의존하는 '사용되는 객체'클래스의 변경
class A{
	public 반환형 메서드1(){
      I i = new B(); 
      i.methodX();
    }
}

interface I{
	methodX();
}

class B implements I{
	methodX(){
    	...
    }
}
class C implements I{
	methodX(){
    	...
    }
}

A클래스의 메서드1를 어떻게 수정할 것인가? 다음 코드와 같이 변경할 것이다.

//인터페이스에 의존하는 '사용하는 객체' 클래스의 한 곳을 수정
class A{
	public 반환형 메서드1(){
      I i = new C(); //B() - > C()로 변경 
      i.methodX();
    }
}

interface I{
	methodX();
}

class B implements I{
	methodX(){
    	...
    }
}
class C implements I{
	methodX(){
    	...
    }
}

클래스의 의존과 달리 인터페이스의 의존은 한곳만 수정한다.
이처럼 인터페이스를 구현한 '사용되는 객체'클래스를 변경하는 경우 다음과 같은 이점이 있다.
1. 인터페이스는 참조를 받는 유형으로 사용할 수 있으므로 변수의 이름을 변경하지 않아도 된다.
2. 인터페이스가 선언된 메서드를 이용하면 클래스가 바뀌어도 메서드명을 변경하지 않아도 된다.

---

의존성 주입💉

의존성 주입이란 '의존하는 부분을 외부에서 주입하는 것'이다.

'의존하는 부분을 외부에서 주입하는 것'이라는 문장을 보면

• 의존하는 부분이란 '사용하는 객체' 클래스에 사용되는 '사용되는 객체' 클래스가 작성된 상태
• 외부로부터 주입이란 '사용하는 객체' 클래스의 밖에서 '사용되는 객체' 인스턴스를 주입하는 것

기존에는 인스턴스를 생성하는데 new 키워드를 사용했지만 인스턴스 생성과 같은 작업을 프레임워크에 맡길 수 있고 그 역할을 할 수 있도록 기능을 수행하는 것 -> 'DI 컨테이너'

---

DI 컨테이너에게 인스턴스 생성을 위해 지켜야하는 다섯가지 규칙

DI컨터이너에 인스턴스 생성을 맡기고 다음의 규칙을 지키는 것으로 '사용하는 객체' 클래스를 전혀 수정할 수 없게끔 만들 수 있다.

• 규칙 1. 인터페이스를 이용하여 의존성을 만든다.(=의존하는 부분에 인터페이스를 이용한다는 것)
• 규칙 2. 인스턴스를 명시적으로 생성하지 않는다.(=인스턴스 생성에 new 키워드를 사용하지 않는다는 것)
• 규칙 3. 어노테이션을 클래스에 부여한다.
• 규칙 4. 스프링 프레임워크에서 인스턴스를 생성한다.
  (= 인스턴스를 생성하려는 클래스에 인스턴스 생성 어노테이션을 부여한다는 것. 즉 @Component 어노테이션을 부여)
• 규칙 5. 인스턴스를 이용하고 싶은 곳에 어노테이션을 부여한다.(=스프링 프레임워크에 의해 생성된 인스턴스를 이용하는 클래스에 참조를 받는 필드를 선언하고 필드에 @Autowired어노테이션을 부여)

---

스프링부트 핵심 가이드에서 말하는 의존성을 주입하는 방법

• 생성자를 통한 의존성 주입
• 필드 객체 선언을 통한 의존성 주입
• setter 메서드를 통한 의존성 주입

📌인스턴스 생성 어노테이션

어노테이션	개요
@Controller	인스턴스 생성 지시. 스프링 MVC를 이용할 때 컨트롤러에 부여
@Service	인스턴스 생성 지시. 트랜잭셩 경계가 되는 도메인(서비스) 기능에 부여
@Repository	인스턴스 생성 지시. 데이터베이스 액세스(리포지토리) 기능에 부여 부여
@Component	인스턴스 생성 지시. 위 용도 이외의 클래스에 부여

---

Reference📚

• 스프링 프레임워크 첫걸음 - 후루네스 키노시타 마사아키 -
• 스프링부트 핵심 가이드 - 장정우 -