•  09-06-2019
  •  | 
  •  

문제

단점이 있나요?지금은 거의 의존하고 있는 것 같아요.프로젝트가 특정 크기를 초과할 때마다 표준 패턴에 대한 알레르기 반응을 거의 느끼며 즉시 종속성 주입 프레임워크로 다시 연결합니다.

제가 발견한 가장 큰 문제는 이제 막 배우고 있는 다른 개발자들에게 혼란을 줄 수 있다는 것입니다.

또한 그것이 내가 사용하는 언어의 일부라면 기분이 훨씬 나아질 것입니다.하지만 적어도 Java의 경우 꽤 좋은 몇 가지 매우 가벼운 라이브러리가 있습니다.

생각?나쁜 경험이 있나요?아니면 그냥 걱정하지 마세요?

[편집] 답변:종속성 주입 자체에 대한 설명

모호해서 죄송합니다. 마틴 파울러 아마도 내가 할 수 있는 것보다 훨씬 더 잘 설명할 것입니다...노력을 낭비할 필요가 없습니다.

우연히도 이는 아직 널리 실행되지 않고 모든 사람이 속도를 내지 못할 경우 팀과 함께 작업할 때 장벽이 될 수 있다는 한 가지 점을 확인시켜 줍니다.

도움이 되었습니까?

해결책

나는 여기 블로그 게시물에서 가능한 단점 중 일부를 설명했습니다. http://kevin-berridge.blogspot.com/2008/06/ioc-and-di-complexity.html

다른 팁

DI에서 발생하는 문제는 COM 및 다음과 같은 코드에서 발생하는 문제와 동일합니다.

i = GetServiceOrInterfaceOrObject(...)

문제는 이러한 시스템을 코드로는 이해할 수 없다는 점이다.서비스/인터페이스/객체 X가 요청할 수 있는 서비스/인터페이스/객체를 정의하는 문서가 [다른 곳]에 있어야 합니다.이 문서는 유지되어야 할 뿐만 아니라 소스만큼 쉽게 사용할 수 있어야 합니다.

문서가 아주 잘 작성되지 않은 이상 개체 간의 관계를 파악하는 것이 여전히 쉽지 않은 경우가 많습니다.때때로 관계는 일시적이어서 발견하기가 더욱 어렵습니다.

저는 KISS 원칙을 좋아하며 작업에 적합한 도구를 사용하는 것이 중요하다고 믿습니다.특정 프로젝트에서 DI의 이점이 이해하기 쉬운 코드를 작성해야 하는 것보다 더 크다면 DI를 사용하는 것이 좋습니다.

또한, 그것이 내가 사용하고있는 언어의 일부라면 훨씬 나아질 것입니다.

참고로 JDK 6의 일부로 매우 간단하고 기능적인 종속성 주입이 있습니다.가볍고 간단한 종속성 주입이 필요한 경우 이를 사용하세요.

사용 서비스로더 클래스를 기반으로 서비스(또는 서비스의 여러 구현)를 요청할 수 있습니다.

 package dependecyinjection;  
 import java.util.ServiceLoader;  

 public abstract class FooService {  

     public static FooService getService() {  
         ServiceLoader<FooService> loader = ServiceLoader.load(FooService.class);  

         for (FooService service : loader) {  
             return provider;  
         }  

         throw new Exception ("No service");  
     }  

     public abstract int fooOperation();  

 }  

 package dependecyinjection;  
 public class FooImpl extends FooService {  
     @Override  
     public int fooOperation() {  
         return 2;  
     }  
 }

ServiceLoader는 반환되는 서비스 구현을 어떻게 정의합니까?

프로젝트 폴더에 이름이 지정된 폴더를 만듭니다. META-INF/서비스 라는 이름의 파일을 만듭니다. 의존성 주입.FooService.이 파일에는 서비스 구현을 가리키는 줄이 포함되어 있습니다.이 경우:의존성 주입.FooImpl

이는 아직 널리 알려지지 않았습니다.

나는 IO에 대한 대단한 신자이지만 아무도 이해하지 못하는 거대한 xml 구성 파일이 있는 일부 프로젝트를 보았습니다.따라서 xml 프로그래밍에 주의하세요.

제 생각에 가장 큰 단점은 학습 곡선(당신이 지적한 대로)과 추가된 추상화로 인해 디버깅이 더 어려워질 가능성(실제로 학습 곡선의 일부이기도 함)입니다.

나에게 DI는 더 크고 복잡한 시스템에 더 적합한 것 같습니다. 소규모 일회성 앱의 경우 앱이 과도하게 설계될 수 있으며 기본적으로 아키텍처를 준수하는 데 더 많은 개발 시간이 소요됩니다. 그것이 제공하는 가치를 보완할 수 있습니다.

걱정하지 마세요.시간이 지나면 IoC 기술이 대부분의 개발자에게 제2의 천성이 될 것이라고 생각합니다.저는 직장에서 개발자들에게 그것에 대해 가르치려고 노력하고 있는데, 우리가 항상 해왔던 방식에 너무 부자연스러워서 메시지를 전달하기가 어렵습니다.그건 우연히 잘못된 길이었습니다.또한 IoC를 처음 접하는 개발자와 내가 찾은 프로젝트를 처음 접하는 개발자 모두 훨씬 더 힘든 시간을 보냅니다.그들은 IDE를 사용하여 종속성의 흔적을 추적하여 전체가 어떻게 "함께 작동"하는지 이해하는 데 익숙합니다.해당 정보는 종종 난해한 XML로 기록됩니다.

집에서 함께 놀고 있는 사람들을 위해 종속성 주입이 실제로 무엇인지 설명하기 위해 링크를 한두 개 추가할 수 있습니까?그만큼 위키피디아 기사 재미는 있지만 그다지 계몽적이지는 않습니다.

제가 생각할 수 있는 유일한 단점은 지속적인 가상 통화를 통한 작은 성능 저하입니다. :)

@블로그비어드: http://www.martinfowler.com/articles/injection.html 아마도 이 주제에 관한 최고의 기사 중 하나일 것입니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top