내용에 부족함이 있거나 틀린 점이 있으면 알려주세요..
어플리케이션을 개발하면서 Hilt에 대해서 기계적으로 적용하며 사용을 하다가 Factory 패턴과 DI의 차이에 대해서 고민하게 되었다.
위의 차이에 대해 알아보기 전에 IOC에 대해서 알고 넘어가자.
이번 글의 결론부터 말하자면,
Factory Method와 DI 모두 하나의 문제를 해결하기 위한 각각의 다른 방법으로 IOC의 원리를 적용하기 위한 방법이다.
IOC의 관심사는 '작업을 A가 한다(작업이 A에 의함)'의 일반적인 상황에서
'B가 A를 통해서 작업을 실현한다(작업이 B에 의함)'정도가 될 것이고,
위의 Control Flow역전을 위해 사용하는 다양한 방법이 있다.
그리고 B에 A를 사용할 수 있도록 하는 방법에는 Factory Method와 DI를 많이 사용한다.
IOC는 관심사 분리, 상대의 코드를 모르는 상태에서 협업 등에 사용되는 원리이다.
IOC(Inversion Of Control)
일반적인 제어의 흐름을 역전시킨다는 '제어의 역전'이다.
DI와 연결하여 생각하게 되면, 의존성에 관해서만 생각하게 되는데(객체를 밖에서 생성하여 주입),
사실 IOC는 모든 상황에 적용시킬 수 있는 아주 일반적인 방법론이라고 생각하여야 한다.
아주 단순한 예를 생각해보자.
나는 개발자로 어플리케이션을 만들 수 있고,
꽃에 물을 줄 수 있다.
그리고 친구에게 전화를 걸 수 있다.
나는 오늘 9시에 꽃에 물을 줄 것이고, 12시에는 개발을 하고, 18시에 전화를 할 것이다.
이러한 작업을 할 수 있는데, 위의 작업을 내가 선택해서 하는 방법이 일반적인 Control Flow가 될 것이다.
하지만 이러한 Control Flow를 역전시켜보자.
부모님이 친구에게 전화를 시키고, 부모님이 꽃에 물을 주라 하고, 새벽에 일어나서 개발을 하라고 하셨다....
이러한 행위에 대한 Controller가 나에게서 부모님으로 넘어간 현상이 Control이 역전된 현상이라고 볼 수 있다.
여기서 요점은 Control이 역전된 상황인 것이지,
나와 부모님이 어디에 정의가 되고 어떻게 주입이 되는지는 중요치 않다.
다만 부모님이 나를 통해 작업을 한다는 점이다.
(++ 내 어플리케이션 내에서 카카오톡의 로그인을 하려면, 그 카톡 로그인 기능을 카톡이 아닌 내가 실행시킨다. )
부모님은 내가 어떻게 물을 주고 개발을 하고 전화를 하는지에 대해서는 관여하지 못한다.
내가 개발을 하는데 Kotlin을 사용해서 하는지, Java를 사용하는지..
다만 내가 그 행위를 하도록 할 수 있을 뿐이다..
아래의 코드가 맞는가?.. 아마 맞겠지?
class Yoon(){
fun do(){...}
} // 일반적 Flow
class Parents(){
fun do(){...
yoon.do()
...
}
} // IOC .. yoon은 어디서 나오냐?
// factory
Class Parents(){
val yoon = YoonFactory().build()
fun do(){
yoon.do()
}
}
// DI.....Yoon 객체 생성을 Hilt에게 위임
Class Parents(yoon: Yoon){
fun do(){
yoon.do()
}
}
다음 글에서 Factory와 DI에 대해서 알아보기러 하자.
붙임 ) 라이브러리와 프레임워크
프레임워크는 전반적인 주도권이 그 프레임워크에 있으며, 사용자는 그 프레임워크에 필요한 부분만 수정, 작성한다.
적절한 예인지는 모르겠지만, 우리가 아파트에 입주하게 된다고 생각해보자.
아파트의 방구조나, 엘리베이터 등등은 이미 구성되어있지만,
인테리어를 하거나, 수목을 심거나 등은 나에게 달려있다.
라이브러리의 경우는 사용자가 직접 모든 내용을 작성하고 , 필요시에 이를 불러들인다.
프레임워크의 주도권을 프레임워크가 가지는 것과는 다른 차이를 볼 수 있다.
App내의 abstract class는 다른 class의 프레임워크의 역할을 할 수 있다.
기본적인 흐름을 abstract class이 주도권을 가진다.
프레임워크는 사용자를 프레임워크가 불러들여 사용을 하고,
라이브러리는 사용자가 직접 불러들여 사용을 한다.
참조
https://stackoverflow.com/questions/557742/dependency-injection-vs-factory-pattern
Dependency Injection vs Factory Pattern
Most of the examples quoted for usage of Dependency Injection, we can solve using the factory pattern as well. Looks like when it comes to usage/design the difference between dependency injection and
stackoverflow.com
https://velog.io/@gillog/Spring-DIDependency-Injection
[Spring] DI, IoC 정리
DI(Dependency Injection)란 스프링이 다른 프레임워크와 차별화되어 제공하는 의존 관계 주입 기능으로,객체를 직접 생성하는 게 아니라 외부에서 생성한 후 주입 시켜주는 방식이다.DI(의존성 주입)
velog.io
https://stackoverflow.com/questions/3058/what-is-inversion-of-control
What is Inversion of Control?
Inversion of Control (IoC) can be quite confusing when it is first encountered. What is it? Which problem does it solve? When is it appropriate to use and when not?
stackoverflow.com
https://martinfowler.com/bliki/InversionOfControl.html
bliki: InversionOfControl
a bliki entry for InversionOfControl
martinfowler.com
https://martinfowler.com/articles/injection.html#InversionOfControl
Inversion of Control Containers and the Dependency Injection pattern
Explaining the Dependency Injection pattern, by contrasting it with Service Locator. The choice between them is less important than the principle of separating configuration from use.
martinfowler.com
https://javacan.tistory.com/entry/120
[번역] IoC 콘테이너와 디펜던시 인젝션 패턴
Spring, PicoContainer 등 경략 콘테이너의 주요 개념인 IoC에 대해서 살펴본다. 디펜던시 인젝션 패턴을 살펴보기에 앞서 본 글은 마틴 파울러(Martin Fowler)가 작성한 'Inversion of control Containers and th..
javacan.tistory.com
'안드로이드 읽어보기 > 6. DI(Hilt)' 카테고리의 다른 글
2) Factory Method와 DI(Dependency Inject,Hilt) (0) | 2022.05.20 |
---|