IoC와 DIP, DI는 항상 혼동되고 지금도 나한테는 어렵다.

클린 아키텍처 책을 읽고 다양한 글을 읽어도 봤는데 직관적으로 이해가 되지 않았다.

면접보러 다녔을 때 DI만 물어보는 곳도 있었고 전체 다 물어보는 곳도 있었다.

또한 앞으로 제대로된 논의를 하기 위해서 정확하게 개념정리가 필요하다고 해서 다시 수정했다.

To be sure, using DI or IoC with DIP tends to be more expressive, powerful and domain-aligned, but they are about different dimensions, or forces, in an overall problem. DI is about wiring, IoC is about direction, and DIP is about shape.

IoC, DIP, DI 는 다른 개념이다. 목적과 요구하는 바가 다르다. 서로 배척하는 개념은 아니지만 함께 했을 떄 강한 에너지가 생긴다.

Inversion of Control (IoC, 제어의 역전)

<aside> 💡 don't call me, I'll call you

</aside>

개발자적으로 풀어서 설명하면 "IoC란 코드의 흐름을 제어하는 주체가 바뀌는 것이다"

코드의 흐름을 제어한다는 것은 여러 행위를 포함한다. 오브젝트를 생성하고, 생명주기를 관리하고, 메소드를 수행하는 것 등...일반적인 프로그램은 이러한 행위를 하나부터 열까지 모두 스스로 수행한다. IoC를 적용한다는 것은 이러한 흐름 제어를 또다른 제 3자가 수행한다는 것을 의미한다.

안드로이드에서도 IoC가 적용된 케이스를 볼 수 있다.

class MainActivity : AppCompatActivity() {
	
		override fun onResume() {
        super.onResume()
				/* .. */
    }

    override fun onPause() {
        super.onPause()
				/* .. */
    }

}

생명주기 메소드가 호출되었을 떄 동작만 정의하고, 언제 생명주기 메소드를 호출 할지는 신경쓰지 않는다. 즉, 액티비티의 메인 흐름 제어권은 나의 코드가 아니라 안드로이드 플랫폼에서 쥐고 있다.

"프레임워크와 라이브러리의 차이는 무엇인가요?" 에 대해 IoC 관점으로 설명이 가능하다. 라이브러리는 내 코드가 라이브러리를 이용한다. 즉, 제어권이 내 코드에 있다. 반면 프레임워크는 프레임워크가 나의 코드를 실행한다.(제어권은 프레임워크에게 있다)

Software frameworks, callbacks, schedulers, event loops, dependeny injection, and the template method are examples of design patterns that follow the inversion of control principle