[2022]NaverMeetup_[Flutter] Dependency Injection과 Service Locator_임태규.pdf

[Flutter] Dependency
Injection과 Service Locator

임태규
• 정보관리 기술사
• 11년차 모바일 엔지니어
(안드로이드, 플러터)
• 전) 삼성전자
• 전) 쿠팡
• 현) Presto Labs
• https://github.com/dualcoder-pe
• https://www.linkedin.com/in/taekyu-lim-b3b629187

Presto Labs
• Global Top Tier High Frequency Trading Firm
• Singapore, Shanghai, Seoul + Remote (Global)
• https://aqx.com
• Mobile, BE, FE 채용 (링크)

목차
Dependency Injection과 Service Locator
Flutter에서 Dependency Injection과 Service Locator
1
2

Dependency Injection과
Service Locator
Part 1

논의의 소재
객체지향 프로그래밍
SOLID
객체
클래스
캡슐화
추상화
다형성
Dependency Injection
Service Locator
IoC

• 객체 지향 프로그래밍은 컴퓨터 프로그램을 명령어의 목록으로
보는 시각에서 벗어나 여러 개의 독립된 단위, 즉 객체들의
모임으로 파악하고자 하는 것이다.

애플리케이션
객체 객체 객체

객체들을 잘 모으려면
어떻게 해야 할까?

응집도는 높게, 결합도는 낮게
SOLID
IoC
Service Locator

예제 프로젝트 구조
App Bloc UseCase Repository
Main View DataSource

응집도와 결합도
• 응집도(cohesion)
• 모듈 내부 구성요소 간 연관 정도
• 응집도가 높다 ➔ 모듈 내 모든 기능이 단일 목적을 위해 수행됨
• 결합도(coupling)
• 모듈과 외부 모듈의 연관 정도
• 결합도가 낮다 ➔ 모듈이 기능 수행을 위해 다른 모듈에 의존하지 않음

class SendOrderUsecase {
final OrderRepository _orderRepository = OrderRepository();
Future<OrderResult> sendOrder(Order order) =>
_orderRepository.sendOrder(order);
}
높은 결합도

class OrderRepository {
final LocalDatasource _localDatasource = LocalDatasource();
final RemoteDatesource _remoteDatesource = RemoteDatesource();
Future<OrderResult> sendOrder(Order order) async {
final localRes = await _localDatasource.sendOrder(order);
final remoteRes = await _remoteDatesource.sendOrder(order);
return OrderResult((localRes && remoteRes) ? "SUCCESS" : "Fail");
}
}
높은 결합도

SOLID
• Single Responsibility Principle: 단일 책임 원칙
• Open Closed Principle: 개방 폐쇄 원칙
• Liskov Substitution Principle: 리스코프 치환 원칙
• Interface Segregation Principle: 인터페이스 분리 원칙
• Dependency Inversion Principle: 의존성 역전 원칙
➔ 구체적인 대상이 아니라, 추상적인 대상에 의존해야 함

DIP 적용
UseCase Repository DataSource UseCase
Repository
DataSource
Repository
Impl

class OrderRepository {
}
}
abstract class OrderRepository {
Future<OrderResult> sendOrder(Order order);
}
DIP 적용

DIP 적용
class OrderRepositoryImpl implements OrderRepository {
final localRes = await _localDatasource.sendOrder(order);
final remoteRes = await _remoteDatesource.sendOrder(order);
return OrderResult((localRes && remoteRes) ? "SUCCESS" : "Fail");
}
}

final OrderRepository _orderRepository = OrderRepositoryImpl();
}
DIP 적용
아직 구체적인 대상에 대한
의존성을 제거하지 못함

IoC
• 애플리케이션의 제어권을 개발자가 갖지 않고 외부에 위임
• Ex) 안드로이드에서 Lifecycle 별로 프레임워크에서 callback 함수를
호출

IoC 적용을 위한 패턴
• Template Method
• Strategy
• Factory Method
• Abstract Factory
• Dependency Injection
• Service Locator
➔ Interface 구현체와, Interface를 사용하는 App Code를 분리

• 의존성 주입
• 객체가 의존성을 외부에서 전달받는 패턴
UseCase
Repository
DataSource
Repository
Impl
누군가

• 의존성 주입 유형
• 생성자 주입
• Setter 주입
• 인터페이스 주입

• 객체의 생성자를 통해 외부에서 의존성을 주입
생성자 주입
final OrderRepository _orderRepository;
SendOrderUsecase(this._orderRepository);
}

late OrderRepository _orderRepository;
set orderRepository(OrderRepository orderRepository) =>
_orderRepository = orderRepository;
}
• 객체를 생성한 뒤, 인스턴스의 setter를 통해 의존성을 주입
Setter 주입

OrderRepository? _orderRepository;
set orderRepository(OrderRepository orderRepository) =>
_orderRepository = orderRepository;
_orderRepository?.sendOrder(order) ?? Future.value(OrderResult("Fail"));
}
• 객체를 생성한 뒤, 인스턴스의 setter를 통해 의존성을 주입
Setter 주입

누군가가 누군가?
(주입은 누가 해주나?)

생성자 주입 – Pure DI
void main() {
runApp(
OrderApp(orderBloc:
OrderBloc(SendOrderUsecase(OrderRepositoryImpl()))));
}

Setter 주입 - Pure DI
void main() {
runApp(OrderApp(
orderBloc: OrderBloc(
SendOrderUsecase()..orderRepository = OrderRepositoryImpl())));
}

• 원인
• Composition Root가 Entry Point와 가까워야 함
• 한계
• 의존관계 tree의 depth가 깊을 때, 안쪽까지 객체를 전달하기 불편함
Pure DI의 한계
App Bloc UseCase
Repository
Repository
Impl
누군가
가까이
Composition Root
Entry Point
Depth

• 애플리케이션에 필요한 모든 객체를 알고 있는 객체를 만들고, 그
객체를 통해 의존성을 획득하는 방법
Service Locator
App Bloc UseCase
Repository
Repository
Impl
누군가
Composition Root
Entry Point
어딘가
Service Locator

• Service Locator의 유형
• Static Service Locator
• Dynamic Service Locator
Service Locator

class ServiceLocator {
static ServiceLocator? _instance;
ServiceLocator(this._orderRepository);
static void load(ServiceLocator serviceLocator) => _instance = serviceLocator;
static OrderRepository getOrderRepository() => _instance!._orderRepository;
}
Service Locator 구현

Service Locator 객체 생성
void main() {
ServiceLocator.load(ServiceLocator(OrderRepositoryImpl()));
runApp(OrderApp(orderBloc: OrderBloc(SendOrderUsecase())));
}

final OrderRepository _orderRepository = ServiceLocator.getOrderRepository();
}
Service Locator 의존성 획득

Dynamic Service Locator 구현
class DynamicServiceLocator {
static DynamicServiceLocator? _instance;
final HashMap<String, dynamic> _services = HashMap();
static void load(DynamicServiceLocator serviceLocator) =>
_instance = serviceLocator;
void loadService(String key, dynamic object) => _services[key] = object;
static dynamic getService(String key) => _instance!._services[key];
}

void main() {
DynamicServiceLocator locator = DynamicServiceLocator();
locator.loadService("OrderRepository", OrderRepositoryImpl());
DynamicServiceLocator.load(locator);
}
Dynamic Service Locator 객체 생성

final OrderRepository _orderRepository =
DynamicServiceLocator.getService("OrderRepository");
}
Dynamic Service Locator 의존성 획득

Service Locator는
안티 패턴이다
- mark seemann -

• 종속성을 숨김
• 단위테스트 어려움
• mocking이 가능하더라도, 전역 메모리 사용하므로, 테스트 후 clear 필요
• 전역 싱글톤 패턴
• 구현 상 전역 싱글톤을 안쓰더라도, 내부적으로 공유 메모리 사용을 피할 수 없음)
• 모든 클래스가 로케이터와 커플링
• Runtime Error
• Locator의 존재를 모르고 생성을 안하고 사용하면 런타임 에러
• 의존 객체를 찾기 어려움
• 내부에 의존성 추가되면 컴파일러가 알 수 없음
• 캡슐화 위반
• 객체 사용을 위한 전제 조건을 알 수 없음
Service Locator의 단점

• GetX
• GetIt
• InheritedWidget
• Provider/Riverpod
➔ InheritedWidget, Riverpod은 상태관리
Flutter DI 라이브러리

void main() {
Get.lazyPut<OrderRepository>(() => OrderRepositoryImpl());
}
GetX의 Injection 방식

GetX의 Injection 방식
final OrderRepository _orderRepository = Get.find();
}

DI와 GetX의 비교 – DI
class OrderApp extends StatelessWidget {
const OrderApp({Key? key, required this.orderBloc}) : super(key: key);
final OrderBloc orderBloc;

class OrderBloc {
final SendOrderUsecase _sendOrderUsecase;
OrderBloc(this._sendOrderUsecase);

final LocalDatasource _localDatasource;
final RemoteDatasource _remoteDatesource;
OrderRepositoryImpl(this._localDatasource, this._remoteDatesource);

void main() {
runApp(OrderApp(
orderBloc: OrderBloc(SendOrderUsecase(
OrderRepositoryImpl(LocalDatasource(), RemoteDatasource())))));
}

OrderApp({Key? key}) : super(key: key);
final OrderBloc orderBloc = Get.find();
DI와 GetX의 비교 – GetX

class OrderBloc {
final SendOrderUsecase _sendOrderUsecase = Get.find();
final OrderRepository _orderRepository = Get.find();
final LocalDatasource _localDatasource = Get.find();
final RemoteDatasource _remoteDatesource = Get.find();

void main() {
Get.lazyPut(() => OrderBloc());
Get.lazyPut(() => SendOrderUsecase());
Get.lazyPut<OrderRepository>(() => OrderRepositoryImpl());
Get.lazyPut(() => LocalDatasource());
Get.lazyPut(() => RemoteDatasource());
runApp(OrderApp());
}

DI와 GetX의 비교
App Bloc UseCase
Repository
Repository
Impl
누군가
Composition Root
Entry Point
Service Locator
누군가 어딘가
Composition Root
DI
GetX

GetX는 Service Locator
패턴

GetX를 Service Locator로만
쓸 수 있을까?

GetX를 DI Container로 활용하기
App Bloc UseCase
Repository
Repository
Impl
누군가
Composition Root
Entry Point
Service Locator
누군가 어딘가
Composition Root
DI with GetX
GetX
어딘가
Get

• DI는 원칙과 패턴
• 지금까지 본 DI는 Pure DI
• 외부 라이브러리나 객체 사용 없이 의존성 주입
• DI Container
• 의존성 주입할 모든 객체를 관리하는 모듈
• 역할 (RRR)
• Register: 인스턴스 등록
• Resolve: 인스턴스 제공
• Release: 인스턴스 해제
Pure DI와 DI Container

class Injector {
static void register() {
Get.lazyPut(() => LocalDatasource());
Get.lazyPut(() => RemoteDatasource());
Get.lazyPut<OrderRepository>(
() => OrderRepositoryImpl(Get.find(), Get.find()));
Get.lazyPut(() => SendOrderUsecase(Get.find()));
Get.lazyPut(() => OrderBloc(Get.find()));
}
}

void main() {
Injector.register();
runApp(OrderApp(orderBloc: Get.find()));
}

const OrderApp({Key? key, required this.orderBloc}) : super(key: key);
final OrderBloc orderBloc;

class OrderBloc {
final SendOrderUsecase _sendOrderUsecase;
OrderBloc(this._sendOrderUsecase);

final LocalDatasource _localDatasource;
final RemoteDatasource _remoteDatesource;
OrderRepositoryImpl(this._localDatasource, this._remoteDatesource);

• 장점
• GetX의 Memory Management 기능 활용 가능
• Entry Point에서 가까운 Composition Root에서 의존관계 관리
• 의존관계 tree의 depth가 깊어도, 안쪽까지 객체를 쉽게 전달
• 단점
• GetX에 등록을 잊는다면, 여전히 Runtime Error 발생 가능

예외적으로 Composition Root가
아닌 곳에서 주입하고 싶다면?

SendOrderUsecase([OrderRepository? orderRepository])
: _orderRepository = orderRepository ?? Get.find();
}

• 예외적으로 생성자에서 객체 생성해 주입 허용
• 외부에 의존관계 알림
• 테스트 용이
• 객체 주입 용이
• 단, 모든 객체가 GetX 의존성 가짐

• 원인
• 객체를 생성 및 조립한 후 변경이 불가능함
• 한계
• 객체 생성에 Runtime 요소가 필요할 때 대응이 어려움
• 보완
• 추상 팩토리 메서드 패턴 활용
한계 및 보완

• 의존성 있는 객체간 결합도를 낮추는 방법
• DI: 생성자 주입, Setter 주입
• Service Locator: 의존성 필요한 객체가 컨테이너에 객체 요청
• Service Locator는 안티패턴이라는 주장 (Mark Seemann)
• Flutter의 의존성 주입 (GetX, GetIT) ➔ Service Locator 방식
• GetX, GetIt을 DI Container로 활용할 수 있음
• 객체 생성에 Runtime 요소가 필요할 경우, 추상 팩토리 패턴으로 보완
정리

[2022]NaverMeetup_[Flutter] Dependency Injection과 Service Locator_임태규.pdf

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to [2022]NaverMeetup_[Flutter] Dependency Injection과 Service Locator_임태규.pdf

Similar to [2022]NaverMeetup_[Flutter] Dependency Injection과 Service Locator_임태규.pdf (20)

[2022]NaverMeetup_[Flutter] Dependency Injection과 Service Locator_임태규.pdf