지금까지 공부한 코드에서는 SRP, DIP, OCP가 적용되어있다.
SRP 단일 책임 원칙
클라이언트 객체 == 구현 객체
초기에 멤버서비스임플과 같은 구현 객체(클라이언트 객체) 에서 직접 구현 객체(메모리멤버리포지토리객체)를 생성하고 ,연결하는 등 다양한 책임을 가지고 있었다.
하지만
AppConfig를 생성하면서 클라이언트 객체는 실행하는 책임만 담당한다.
DIP 의존관계 역전 원칙
OCP
다형성을 사용하고 클라이언트가 DIP를 잘 지키면 OCP가 적용될 가능성이 열린다.
IoC( Inversion of Control, 제어의 역전)
보통은 개발자가 원하는 객체를 생성하고 그 객체안에서 다른 객체도 생성하면서 직접 컨트롤하면서 개발을 하는데
-> ex) 멤버서비스임플 구현체의 코드를 짜면서 그 안에서 필요한 객체인 메모리멤버리포지토리 구현체도 생성하면서 넣연결하고 실행했던것 처럼
제어의 역전은 자신이 호출하는게 아니라 프레임워크 같은게 내 코드를 대신 호출해 주는것이다. (제어권이 뒤바뀐다고해서 제어의 역전)
-> AppConfig가 등장하고 구현객체는 자신의 로직을 실행하는 역할만 담당한다. 프로그램의 제어흐름은 이제 AppConfig가 가져간다.
ex) 멤버서비스임플 구현체는 이제 그안에서 필요한 객체를 직접 생성하지않고 인터페이스 변수를 생성하여
구현체를 주입받는다. + 어떤 구현 객체를 주입받을지 모른다.
프로그램에 대한 제어 흐름 권한은 모두 AppConfig가 가지고 있다. 심지어 오더서비스임플(클라이언트 객체)도 AppConfig가 생성한다. AppConfig는 오더서비스임플이 아닌 다른 인터페이스 구현객체를 생성하고 실행할 수 있다.
클라이언트 객체는 그저 자신의 로직을 실행할 뿐이다. (어떤 구현객체를 쓸지 AppConfig에서 결정)
이렇게 프로그램의 제어 흐름을 직접 제어하는것이 아니라 외부에서 관리하는 것을 제어의 역전(IoC)이라고 한다.
프레임워크와 라이브러리를 구분할때 IoC(제어의 역전)이 중요하다.
ex) JUnit을 이용한 테스트처럼 , 개발자가 테스트할 로직만 짜주면 JUnit 프레임워크가 자신만의 사이클대로 실행시켜준다.
DI(Dependency Injection , 의존관계주입, 의존성 주입)
클래스 다이어그램
클래스다이어그램만 봐서는 어떤 객체가 주입될지 모른다
그래서 있는게
IoC 컨테이너 ,DI 컨테이너
AppConfig 처럼 객체를 생성하고 관리하고 의존관계를 연결시켜주는것 == IoC 컨테이너 or DI 컨테이너
요즘에는 DI 컨테이너로 많이 불린다. [ == 의존관계 주입을 해주는 컨테이너]
댓글