RoboGuice 쓰라고 적혀 있네요.

은주 아 저런 스타일을 원했었어요~ 감사~^^

클라이언트 어플은 DI Container의 효용이 낮더군요. 클라이언트는 객체 간의 계층구조가 뚜렸해서 깊숙한 곳에서 생성되는 객체가 외부 의존성을 간편하게 얻으려면 DL로 갈 수 밖에 없었을듯.

은주 아 '깊숙한 곳에서 생성되는 객체'라니까 떠오르는데, 유난히 method chain이 길어보이는 코드가 많이 보이는 것도 그래서 그렇나보네요

benelog 메소드 체인의 길이가 긴 경우는 보통 중간에 있어야 하는 추상화된 컴포넌트가 없고 고수준 컴포넌트에서 시스템에서 제공하는 텍스트필드나 테이블의 셀 같은 저수준 컴포넌트를 직접 접근할 때 그런 모양이 나옵니다.

GUI에서는 조금만 방심하면 금방 길어지죠.

은주 그렇군요~ 나중에 코드 보면서 자세히 이야기 나눌 기회가 있으면 좋겠네요. 감사~

은주 깊숙한 곳에서 생성되는객체와 외부 의존성이 어떤 관계인거지? 어차피 인터페이스로 보이는거아님감?

ologist 코드에서 new로 생성하는 객체에 DI 컨테이너가 개입해서 필요한 외부 인터페이스 주입 못하는 문제죠. LTW 쓰면 되겠지만.

GUI 프로그래밍에서는 코드에서 new로 생성한 객체에 외부 인터페이스를 주입해야 하는 경우가 많습니다. 코드에서 new로 객체를 생성하면 컨테이너가 개입할 수 없으니 객체가 필요한 외부 의존성을 DL로 얻을 수 밖에 없죠.

RoboGuice도 RoboActivity.onCreate에서 DI 같이 DL을 하네요.

은주 DI같은 DL이 injector.injectMembers(this); 코드를 말씀하시는 것인가요? 메소드 호출때마다 의존성 주입이 되니 new로 생성한 효과도 만들 수 있겠네요.

은주 처음에 저는 javax.inject.Provider와 같은 스타일도 생각해봤엇습니다 ^^; 아뭏든 '깊숙한 곳에서 생성되는 객체'가 어떤 것을 말씀하신 것인지는 이제 어느 정도 이해가 가는 것 같네요.

네 injectMembers 맞습니다. injectMembers 좋네요