의존성 주입

그거 정말 별거 없는데...ㅎㅎ 

이렇게 쉬운 걸 쓸때없이 어려운 용어/사상/구분짓기로 떡칠을 해서,  오히려 개발자들에게 짐을 지우는게 아닌가 싶은..

그냥 객체(모듈,개체,구조체등등) 이 있다고 할 때, 특정 역할을 외부에서 객체/포인터/함수등 무엇이든 주입받아서 해결하는 방식(근데 애들 관리가 힘들어 질 수도..숨박꼭질 하는 애들 종적찾기란..) 주입받는 방식은 기술,언어마다 다를 수도 있으며 생성자를 이용하던, 세터를 이용하던 채널을 이용하던 소켓이나 파이프를 이용하던, 설정파일에 적혀있던 리플렉션을 이용하던 뭐던간에 자신이 다 구현해서 하드코딩되는 것보다 유연해지겠지요. 

이게 특정 프레임워크나 언어에서 유행했다고 해서, 그것이 정답 및 진정한 xxx 류가 될 수 없으며 그냥 유연하게 설계 하기 위한 모든 스프트웨어 세상에서의 나타나는 일반적인 패턴 정도로 바라보면 편할 듯 싶네요. 

한글 위키백과 보니깐 "의존성 주입(Dependency Injection, DI)은 프로그래밍 에서 구성요소간의 의존 관계가 소스코드  내부가 아닌 외부의 설정파일 등을 통해 정의되게 하는 디자인 패턴  중의 하나이다." 이렇게 나오는데, 누가 정의 했는지 정말 지엽적으로 지껄여 놨구나.... 그냥 그런식으로 하는 방식, 또는  life cycle 까지 관리해주는 프레임워크가 있는것 일뿐..잘못된 정의

아래 장,단점도 가져왔는데요. 전 한번 읽어봤는데 이딴거 읽을 필요도 없을거 같아요. ㅎㅎ
웬만한 프로젝트엔 저 단점이 장점보다 훨씬 크지 않을까 의심스러운데.. 뭐 일일이 확인 해 볼 순 없지만서도..암튼 소는 누가 갈고~코딩은 어느세월에 합니까~이런거에 발목 잡혀서...

문법 실수에 겁내서 말하기를 즐기지 못했더라면  오성식은 유창하게 영어를 할 수 없었다.

장점[edit ]

• Dependency injection allows a client the flexibility of being configurable. Only the client's behavior is fixed. The client may act on anything that supports the intrinsic interface the client expects.
• Dependency injection can be used to externalize a system's configuration details into configuration files, allowing the system to be reconfigured without recompilation. Separate configurations can be written for different situations that require different implementations of components. This includes, but is not limited to, testing.
• Because dependency injection doesn't require any change in code behavior it can be applied to legacy code as a refactoring . The result is clients that are more independent and that are easier to unit test  in isolation using stubs  or mock objects  that simulate other objects not under test. This ease of testing is often the first benefit noticed when using dependency injection.
• Dependency injection allows a client to remove all knowledge of a concrete implementation that it needs to use. This helps isolate the client from the impact of design changes and defects. It promotes reusability, testability and maintainability.[22] 
• Reduction of boilerplate code  in the application objects, since all work to initialize or set up dependencies is handled by a provider component.[22] 
• Dependency injection allows concurrent or independent development. Two developers can independently develop classes  that use each other, while only needing to know the interface the classes will communicate through. Plugins  are often developed by third party shops that never even talk to the developers who created the product that uses the plugins.
• Dependency Injection decreases coupling between a class and its dependency.[23] [24] 

단점[edit ]

• Dependency injection creates clients that demand configuration details be supplied by construction code. This can be onerous when obvious defaults are available.
• Dependency injection can make code difficult to trace (read) because it separates behavior from construction. This means developers must refer to more files to follow how a system performs.
• Dependency injection frameworks are implemented with reflection or dynamic programming. This can hinder use of IDE automation, such as "find references", "show call hierarchy" and safe refactorings.
• Dependency injection typically requires more upfront development effort since one can not summon into being something right when and where it is needed but must ask that it be injected and then ensure that it has been injected.
• Dependency injection forces complexity to move out of classes and into the linkages between classes which might not always be desirable or easily managed.[25] 
• Dependency injection can encourage dependence on a dependency injection framework.[25] [26] [27] 
  
  

술한잔하고 누군가의  잘 모르겠다는 넉두리에 주저리 주저리 해봄.