최근들어 팰콘을 보고있는 카이도입니다 ㅎㅎ

dependency injection 의존성 주입 패턴

어디선가 한번쯤은 들어보셨을것입니다. 잘 아시는 분도 계실테구요.

이 의존성 주입.. 약자로 DI . 

DI 를 아주 간단하게 설명 해드리자면 이겁니다.

어디에도 사용 가능하게 객체를 만들어두기.

즉 한번 만들어서 생성된 상태이라면 A컨트롤러든 B  컨트롤러든 가져올수 있습니다.

B컨트롤러의 값을 A로 가져올수도 있구요. [주입하면 말이죠.]

와우! 멋진데요?

사실 CI측에서도 이전부터 제기되어오던 문제이기도 했습니다.

팰콘만 아니라 라라벨를 포함 최근 업데이트되고 있는 프레임워크나 신규 프레임워크에는 대부분이 이 DI가 들어가 있습니다.

그래서 CI4에는 넣는걸로 픽스가 되어있긴 합니다만...

막상 이게 들어간 프로젝트 소스를 보다보니 의문이 들더군요.

이거 정말 좋은거 맞아?

참 좋아요. 네 좋은거 알겠는데... 이 DI 의존성 주입 하는게 어디서 되어있는지 명시가 되지 않게 만들면....

갑자기 뚱딴지 같이 객체 생성도, 혹은 use interface 도 안했는데 $this 객체로 갑자기 똻! 하고 사용이  가능 합니다.

그런데 이게 어디서 선언 되어서 만들어진 객체인지 알 길이 없습니다.

하물며 그게 프레임워크에서 기본으로 제공하는 라이브러리가 아닌 개인이 만들거나 혹은 컴포저로 따오거나 등등 하면 추적하다가 길을 잃고 미아되기 쉽상입니다.

네. 이거 양날의 검이네요.

아 참고로 CI3.x에서도 이 DI 구현해서 쓸수는 있습니다.

로더 코어를 수정하면 말이죠.

단지 정신건강을 위해서 말리고 싶을 뿐입니다.

막상 만들어도 신기할뿐 그렇게 도움이 된다는 인상도 없습니다.

평범하게 사용해도 충분히 프로그램 하는데 지장 없습니다.

팰콘과 라라벨의 경우엔 이 DI를 기준으로 MVC패턴을 만들었기 때문에 어쩔수 없이 들어간 부분도 없지 않아 있어서 쓰는거라 생각 됩니다.

다만... 딱히 없어도 될지 모르는 interface 이라는 이런 물건을 OOP 에서  만들고 포함시키는 이유를 상기해보면 , DI는 이를 위배하는게 아닌지 하는 생각도 들긴 합니다. [위배한다 해도 딱히 벌금은 없습니다 >_<]

뭐 이런말을 하면서도 저는 trait 기능을 선호 하고 있지만 말이죠 ㅋㅋㅋ