[iOS - swift] Clean Code(클린 코드) - 10. 시스템 (Abstract Factory 패턴, DI)

시스템을 만드는 것

• 도시를 만드는 것과 동일한 것이며, 도시를 세운다고 했을때 혼자서 도시를 만들기는 불가능하지만 각 수도 관리 팀, 전력 관리 팀, 교통 관리 팀들이 적절한 추상화와 모듈화에 의해서 효율적으로 돌아가는 방식
• 소프트웨어 팀도 시스템 수준에서도 깨끗함을 유지하는 방법이 중요

시스템 제작과 시스템 사용을 분리할 것

• 생성(Construction)과 사용(Use)의 차이
  
  • 시스템 생성: 의존성을 연결하는 준비 과정
  • 시스템 사용: 준비 과정 이후에 이어지는 런타임 로직
• 시스템 생성과 시스템 사용을 분리하는 대표적인 방법 - DI(Dependency Injection)
• 시스템 제작과 세스템 사용을 분리해야하는 근본적인 이유: "관심사"를 분리함으로서 SRP원칙을 준수하기 위함

1) 생성과 사용 분리 방법 - Main 분리

• 생성과 관련한 코드 모두 main이나 main이 호출하는 모듈로 이동
• 나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정
• main 함수에서 시스템에 필요한 객체를 생성 한 후 애플리케이션에 넘기고, 애플레이케이션은 그저 이 객체들을 사용
• 모든 화살표가 main에서 애플리케이션쪽을 향하므로, 애플리케이션은 main이나 객체가 생성되는 과정을 모르는 상태

출처: Clean Code

2) 생성과 사용 분리 방법 - Abstract Factory 패턴

• 객체가 생성되는 시점을 애플리케이션이 결정할 필요가 생길 때 필요한 방법
• ex) 주문 처리 시스템
  • 상황 - 애플리케이션이 LineItem인스턴스를 생성하여 Order에 추가
  • 해결 - Abstract Factory 패턴을 이용하여, LineItem을 생성하는 시점은 애플리케이션이 결정하지만 LineItem을 생성하는 코드는 애플리케이션이 모르는 상태
• 모든 의존성이 main에서 OrderProcessing 애플리케이션으로 향하므로, OrderProcessing 애플리케이션은 LineItem이 생성되는 구체적인 방법을 모르는 상태
• 생성되는 방법은 main쪽에 LineItemFactoryImpl이 아는 상태

출처: Clean Code

3) 생성과 사용 분리 방법 - DI (Dependency Injection)

• DI 의존성 주입은 제어 역전 (Inversion Of Control) 기법을 의존성 관리에 적용한 메커니즘
• IOC 제어 역전에서는 한 객체가 맡은 보조 책임을 새로운 객체에게 떠넘기는 형태
  • DI에서의 책임: 의존성 자체를 인스턴스로 넘기는 책임
  • 해당 책임을 다른 '전담' 컴포넌트인 `컨테이너`에게 넘기는 것
• 클래스가 의존성을 해결하려 시도하지 않고, 클래스는 온전히 수동적인 성격이고 DI 컨테이너는 필요한 객체의 인스턴스를 만든 후 의존성 설정
  • DI를 통해 생성, 사용간의 관심사 분리가 가능
  • testable한 코드 확립이 가능 (의존성만 주입하여 테스트에 필요한 mock 클래스 생성이 용이)

cf) DI 예제 코드: https://ios-development.tistory.com/710

 

* 참고: Clean Code (로버트 C. 마틴)