TLDR

경험적 데이터는 관련이 없습니다. DI와 같은 도구 및 사례는 특정 문제를 해결합니다. 문제를 이해하고 도구를 사용하는 방법을 배우면 도구가 가치가있을 때 분명해 지며 결과를 일반화되고 집계 된 경험적 데이터보다 훨씬 더 예언 적으로 설명 할 수 있습니다.

---

그리고 지금, 훨씬 더 장황한 …

경험적 증거가 있습니까?

아마 요 아니면 적어도 어쩌면 그러나 누가 신경 쓰나요? 관련이 없습니다.

DI의 통계적 비용-이익 분석은 학문적으로 흥미로울 수 있지만 반드시 개별적인 성공을 예측하는 것은 아닙니다. 집계 된 결과는 개별 성공 및 실패를 숨 깁니다 . 그리고 나는 “복음 주의적”관행에 관한 데이터가 특히 유독하다고 주장 할 수 있습니다. 이러한 원칙은 열심과 바보 모두를 끌어들이는 경향이 있으며, 둘 다 “순수한”구현의 순 영향을 모호하게하며, 둘 중 하나 일 수 있습니다!

그렇다면 Dependency Injection이 가치가 있다는 것을 어떻게 알 수 있습니까?

좋은 질문! 사실 큰 질문입니다. 그리고 나는 당신과 함께 있습니다-나는 아무도 정당화 할 수없는 교의 “모범 사례”에 시간과 정신적 노력을 낭비하는 것을 싫어합니다. 그래서 물어봐서 기뻐요.

어. 그러나 여기 당황스러운 문제가 있습니다 … 일반적 으로 , 당신 은 몰라요. 더욱 부끄럽게도 DI를 도입해도 코드가 실제로 나아지지 않을 수 있습니다.

---

GASP!

    ⊙▃⊙     . . .      (╯°□°)╯︵ ┻━┻

…

---

아마도 지금 궁금해 할 것입니다 …

왜 내가 ‘너덜 너덜 한 것으로 증명되지 않았다’고 귀찮게해야합니까!?

우선, 토론의 모든 측면에서, 그냥 해결하자. 독단주의와 회의론 사이에는 이성과 수준의 향연의 아름다운 천국이 있습니다. (그리고 가끔 편심 SE.SE 게시물.) 그리고 POAP가 당신을 이끌 수 있습니다.

… 즉, 원칙을 적용하는 원리 :

원칙, 패턴 및 관행은 최종 목적이 아닙니다. 그러므로 각각의 훌륭하고 적절한 적용은 우수하고보다 최종적인 목적에 의해 영감을 받고 제한 됩니다.

왜하고있는 일을하고 있는지 이해해야합니다!

(POAP는 POAP에서 면제되지 않습니다.)

^{(나는 “강조 광산”이라고 말하지만 어쨌든 내 자신의 “블로그”에서 온 것입니다. 그래서 그것은 모두 내 것입니다!)}

여기서 요점을 되풀이하겠습니다. 왜하고있는 일을하는 이유를 이해해야합니다.

그리고 분명히 말하면, 일반적으로 주어진 “무언가”(예 : 의존성 주입)를 가져 와서 어떤 문제가 해결되는지 이해하지 않고 사용하는 것이 합리적이지 않습니다 . 문제와 “무언가”(DI와 같은)가 어떻게 작동하는지 이해한다면, 일반화되고 집계 된 경험적 데이터가 제안하는 것과 무관하게 “무언가”가 얼마나 도움이되는지에 대해서는 다소 “분명한”것입니다.

DI의 도움이되는 것 또는 경우 취소 당신의 추론 능력 이상 또는 적어도 – – 당신에게 -helpfulness이 명확하지 않다 당신도 DI를 이해하지 못하는, 또는 당신은 당신의 자신의 문제를 이해하지 않습니다.

---

실제 “비유”를 생각해 봅시다.

상자를 만들어야합니다. 우리는 나무가 있습니다. 손톱이 있습니다. 그리고 표준 클로 망치 와 드라이버 두 가지 도구가 있습니다 .

이제 우리는 스크류 드라이버로 구성된 박스가 망치로 구성된 박스에 비해 전체적으로 상당히 견고한 박스임을 보여주기 위해 광범위한 경험적 데이터를 가질 수 있습니다. 그러나 그 손톱을 조이려고하면 상자가 전혀 없습니다. 그리고 스크루 드라이버로 두들겨 넣으려고하면 결국 들어올 수 있습니다. 그러나 훨씬 더 많은 시간과 노력이 필요하며 최종 결과는 단순히 망치를 사용한 것보다 덜 정확하고 강력합니다.

그리고 누군가가 이전에 어느 툴을 사용하는지 보았고 상자 모양을 이해한다면 결정이 분명합니다.

격동!

어 … 흠 …

---

그래, 의존성 주입은 어떤 문제를 해결합니까?

이 코드는 구성 할 수없는 엄격하고 구성 할 수없는 코드를 방지하기 위해 작동하므로 종종 테스트 할 수 없습니다 .

코드를 호출 하여 모듈이 작동하는 오브젝트를 결정하도록 허용 함으로써이를 수행 합니다. 그리고 나는 당신이 그것을 생각하고 있고 당신이 옳다는 것을 알고 있습니다. 이것은 원격으로 새로운 개념조차 아닙니다. 대수 발생 이후 방법 / 기능 매개 변수가 존재합니다.

우리는 불균형을보기에 충분한 코드를 모아서 상속하면 기본 매개 변수 전달을 시작하여 “종속성 주입”이라고 부릅니다. 의존성이 숨겨져 있기 때문에 우리가 앉아있는 코드의 산은 쉽게 변경, 테스트 또는 재사용 할 수 없었 습니다.

따라서 의존성 주입을위한 열성적인 성전은 …

K. 그러나 나는 논쟁을 잘 전달할 수 있습니다. 왜 프레임 워크 입니까?

내가 이해하는 바와 같이, DI 프레임 워크는 주로 보일러 플레이트 빌드 업 (과도한 DI, IMO로 인한) 문제를 해결합니다. 특히 필요한 모든 모듈에 표준 “기본”종속성이있는 경우에 특히 그렇습니다. DI 프레임 워크는 호출 시점에서 명시 적으로 전달되지 않을 때 이러한 기본 종속성을 제거하기 위해 마법적인 (잠재적으로는 못된!) 작업을 수행합니다. ( 이러한 방식으로 사용될 때 서비스 로케이터 와 같은 효과가 있습니다.)

“수양”으로서의 의존성 주입은 실제로 제대로 이해하기가 어렵습니다. DI 사용 여부는 중요하지 않습니다. 어떤 종속성이 변경 될 가능성이 있는지 또는 조롱하고 주입해야 하는지를 알아야 합니다 . 그런 다음 DI가 서비스 위치와 같은 다른 대안보다 더 적합한 지 결정하는 것이 중요합니다 …

그러나 Google에 권유 하고이 SO 답변을 보고 업계에서 경험이 풍부하고 성공적인 개발자와 이야기하고 CR.SE에 구체적인 예를 게시하십시오 .

---

답변