IOC 제어의 역전

의존성 주입과 서비스 로케이터

제어의 역전(IoC, Inversion of Control)arrow-up-right객체의 생성, 생명주기 관리, 의존성 연결 등 제어 권한을 개발자 코드에서 프레임워크(컨테이너)로 넘기는 설계 원칙

IOC 패턴

Interface 구현체와 Interface 사용하는 App Code 분리

대표적으로

DI

  • 누군가는 에서는 Repository, Repository Implementation 를 알고 있고 UseCase 에 넘겨줌

  • usecase 는 더이상 Repository Implementation 를 모르고 Repository 추상클래스만 알면됨

Pure DI

Pure DI 한계

Composition Root(주입해주는 외부, 누군가)가 Main() Entry Point 와 너무 가까움

누군가가 어딘가(DI container) 에 객체를 만들고 RepositoryImpl 의 정보를 보관해둠. 위의 Pure DI 단계에서는 누군가가 외부 주입을 해줬다면, 이번엔 UseCase가 어딘가에게 달라고요청 (Service Locator)

Service Locator

  • static (자기가 객체를 가짐)

  • Dynamic (HashMap)

Getx의 Injection 방식패턴

Getx 는 Service Locator, main() 에 get.lazyput 등록해두고 각 레이어 코드에서 get.find() 로 얻어옴

DI Container (의존성 주입할 모든 객체들이 등록되어있고, Service Locator 와 달리 각 레이어의 코드에서 get.find() 요청을 받는 방식이 아닌 외부 주입⇒ Injector)

)

Last updated