사실 대부분의 객체지향 원칙이라는 것은 정확히 말하면 Java 객체 프로토콜으로 프로그래밍할 때의 원칙이죠. Self나 Io처럼 class-based OO가 아니라 prototype-based OO이면 아예 클래스로 추상화한다는 전제 자체가 달라져버리니 원칙을 적용할 수 없겠죠;

꼭 그렇지 않더라도 CLOS 같이 metaobject protocol이 존재한다던가 하면 정말 그 세계에서는 한계가 사라져서 무의미해지는 원칙들도 많이 있다고 봅니다

그래도 서로 다름 패러다임끼리 상통하는 것은 있긴 하다고 생각해요. 예를 들어 중복을 최소화하는 것은 어디서나 같겠죠.

polymorphism도 마찬가지고요. class-based OO라면 그것을 inheritance로 실현하고, prototype-based OO라면 cloning으로, FP에서는 specialization으로… 뭐 그런;;

본의 아니게 엄청난 설리를 달아버린듯… ㅈㅅ;;

ㄴ 미투 가입 이후 가장 어려운 댓글, 도대체 몇 개의 용어가? DI가 뭔지 저도 궁금해지기 시작.. ㅋ

홍민희 괴수님이 도배를 시작하셨어.. ((덜덜..)) 말씀하신대로, first-class functions를 지원하는 언어들과 Java의 객체를 다루는 방법이 많이 다르지만, 전 DI에 대한 논의는 타 언어로 확대가 될 수도 있다고 봅니다. 이미 (어색하게) 하고 있기도 하고요.

다시 원점이지만 개인적으로 "딱 맞는 용도를 찾는 것"이 관건이 아닐까 합니다.

흠. 실장님 저번에 강남에서 저에게 하신 이야기를 하지죠. ㅎㅎ 자바는..

자바는???? (궁금합니다.. )

nephilim 정확히 말하면 DI라는 것은 어떤 언어에서는 단순히 대입 같이 간단하게 가능하기 때문에 dependency injection이라고 거창하게 따로 용어가 만들어질 이유가 없었을 것 같아요

홍민희 : 와우. 멋진 글 갑사합니다. 한동안 머리가 복잡하겠네요. 그런데 ruby나 python도 Prototype base 언어에 속하는 건가요? 전 javascript 정도 밖에 생각 못했는데..

그리고 DI는 사실 언어에 제한을 받을 수 있을지 모르겠지만 IoC는 일반적으로 적용될 수 있을 것 같습니다. DI는 IoC의 한가지 형태일 뿐이니까요.

fupfin 아뇨. Ruby와 Python은 class-based OO인데 Python은 약간 prototype-based OO 영향을 받긴 했습니다. 제 생각에는 CLOS의 metaobject protocol을 접하면 OO에 대한 인식이 완전히 바뀌게 되는 것 같아요;;

맹수 : 그건 이미 이글 의 댓글에 언급이 된 거 같아서.. ^^

홍민희 : 제 뇌를 녹이시는 군요. CLOS는 또 뭐랍니까? ㅎㅎ 아! Common Lisp 뭐시기 뭐시기군요. lisp은 잘 몰라서…;;;

fupfin 제 생각에는 DI가 언어에 제한을 받는다기 보다는, 어떤 언어에서는 그런 논의 자체가 필요 없을 정도로 이미 언어에서 심플하게 가능하다고 보는게 맞는 것 같습니다.

fupfin Java에서 을 사용하는데 언어에 hack을 한다거나 프레임워크까지 만들 필요는 없는데 C에서는 그게 안되니 GObject 같은 걸 써야 하는 것과 비슷하지 않을까요.

어라; 위에 뭔가 짤렸네요. “Java에서 클래스나 상속을 사용하는데…”입니다.

홍민희 : 예. 무슨 말씀인지 이해했습니다. 그런데 마틴 파울러도IoC가 OO적인 문제라고 했으니 그 태두리 안에서만 효용성 여부를 생각하면 될 것 같습니다.

IoC가 OO적인 문제일까요? OO를 구현하다 나온 부차적인 문제라고 봅니다. 자바와 같은 언어에서 유의미한 것이지 모든 OO에서 의미있는 건 아니죠.

홍민희 기능적관점에서는 그런데, 컨테이너를 만들어얻고자하는건 관리의 목적도 있는 것 같습니다. 이건 앞서말한 규모와도연관되구요. 뭐 저도 스프링처럼해야된다 이게아닌데…아ㅜㅜ

암튼 좋은 의견이 더듣고 싶은거지 딴지는 아닙니다 ㅜㅜ

음, 저도 초천재 님과 같은 생각인데요, 마틴 파울러의 권위를 부정하는 꼴이긴 하지만 저는 “IoC가 OO적 문제다”라는 전제가 잘못되었다고 생각하고 그것을 “IoC는 Java OO의 문제다”로 축소해야 맞는 말이라고 생각합니다.

nephilim 사실 규모의 문제가 없진 않는 것 같습니다. 예를 들어 Zope는 Python으로 만들어진 대표적인 “거대” 프레임워크인데 Pythonic하지 못한 부분들이 조금 있죠. 그래도 만든 사람들은 다 Python 고수입니다.

초천재 : 저도 비 Java 영역에서도 의미 있다고 주장하는 건 아니고요. 왜 관심을 못 받는지 (또는 왜 무의미한지) 알아보고 싶은 겁니다. 아직 대답을 찾지는 못한 것 같고요.

DI가 그냥 심플하게 가능한 언어가 있다니 짱이군요! Noop전에 벌써 그런 언어가 있었단 말입니까?

ㄴDI가 간단하게 된다기 보다 어떤 언어에서는 DI라는 것 자체가 필요 없을 수 있다는 말 같은데 아직 잘 모르겠다는 거…

곱씹어볼만한 쓰...쓰레드. [ 글보러가기 ]

아 어렵다! dependency 자체는 설계 시 꽤 중요한 문제라고 생각합니다. OO건 절차적 언어이건 간에요. DI 나 IoC가 java 에서 급물결을 타고 있다면, 다른 언어들에는 dependency 관리를 어찌하고 있는걸까요?

아무리 봐도 홍민희님은 천재이신듯. +_+

적어도 IOC/DI가 자바안에서 이슈가 되는 현상과 자바만 매우 복잡한 도메인에서 있어서 이런 방법이 이슈가 되는건지 궁금하긴 하네요.

루비도 사실 IoC/DI 프레임워크? 라이브러리?가 있더군요. 다만 커뮤니티에서 크게 이슈가 되는지 모르겠지만.

종종 정적 타입 언어가 복잡한 클래스 계층 구조안에서 뭔가 해야하는 것과 관계가 있지 않을까 싶군요. 저같은 초보는 좀 쉽게 접근을. +_+

이 재미있고 흥미진진한 논의를 보면서

맹수 정적 타입이라고 해서 복잡한 클래스 계층 구조가 반드시 생기는 것도 아니고 요즘은 상속대신 구성을 선호하니, 그리고 그런 상황에서도 DI는 더욱 유용하니 그건 아니지 않을까?

오리대마왕 : 저도 그게 궁금하네요.

fupfin 복잡한 클래스 계층이라는 단어에서 구현상속만을 이야기 한것은 아닙니다.

ㄴ 그렇담 그게 왜 Java에만 해당되는 문제지? 객체지향이라면 결합과 응집 문제가 보편적인 것 아닐까?

ㄴ 자바에만 해당되는 문제라 한적은 없고.

ㄴ OOP 에서 결합과 응집 문제가 아니라 복잡한 클래스 계층을 이야기 했는데요?

ㄴ 지금 DI는 자바 같은 정적 타입에서는 의미 있지만 다이나믹 타입에서는 의미가 약하고 그게 클레스 계층이 복잡해서가 아닌지 생각한다고 말하는 것 아니었나?

ㄴ 그리고 복잡한 클레스 계층이라는 말을 내가 잘 이해 못하겠는데 예를 들어 줄 수 있을까?

ㄴ DI가 정적 언어에서 이슈인 점이 정적 타입의 언어의 특징에서 기인한다면

ㄴ 그런 특징중 하나가 복잡한 클래스 계층이 아닐까 싶고.

ㄴ 만일 그러하다면 이 두개가 관계가 있지 않을까 하는 질문이었습니다.

ㄴ 질문보다는 있지 않을까 하는 추측성이긴 한데.

ㄴ 사실 복잡한 클래스 계층의 예는 무엇이 있을까요?

ㄴ 더글라스 크락포드의 자바스크립트 책 서문에 정적언어와의 비교 부분에 복잡한 클래스 계층에 대한 이야기가 있긴 하네요.

ㄴ 하긴 자바스크립트도 프로토타입 기반 언어이긴 한데.

맹수 : 일단 복잡한 계층 클래스의 정체를 파악해봐야겠네. 그런데 프로토타입 기반 언어는 결정을 런타임으로 옮겼을 뿐 복잡도를 없앴다고 할 수 없지 않을까? 내가 설계 신봉자도 아니지만 설계 무용론자도 아니라서…

제어의 역전이라는 것은 객체와 객체간 관계를 "누가" 주도하느냐에 초점을 맞추어야 하는 것이 아닐까요? Spring IoC 첫 예제인 성배찾는 기사 예제에서도 IoC로 해결하는것은 기사가 임무를 찾는게 아니라 누군가 기사에게 임무를 부여하는 것이라 생각했습니다.

이 경우는 복잡한 계층 클래스라는 특성과는 무관하다고 생각합니다. 임무찾는 일을 기사에게서 떨궈내서 보이지 않는 손(컨테이너? ^^)가 해결해 주는 것이 주요한 것이 아닐까요.

오리대마왕 헐리우드 법칙인가요. 저도 첨 DI/IOC을 접할때 이 법칙으로 이해를 시작했던것 같습니다. :-)

오리대마왕 저의 질문은 사실 정적언어의 어떤 점이 그런 특성(DI/IOC)을 나타낼까. 라는 질문이거든요. 이 질문이 옮바른 질문인지도 궁금합니다. :)

오리대마왕 사실 저 기술적인 해결책같은 것보다 적어도 자바진영에서는 DI/IOC가 매우 이슈이고 OOP의 근간이라는 말까지 들었는데. 왜 다른 곳은 조용한가? 라는 궁금증이었거든요.

맹수 : 난 이글 에서 nephilim 님이 말한 게 가장 적절하다고 생각되. IoC를 통한 S/W 구성 개념이 나왔을 때 이에 먼저 호응하고 개발해 적용한 것이 Java 진영이었고 그것이 메인 스트림이 된 것이 요 몇년이니까 아직 다른 영역에 보급이 안 되고 있다고 보고

보급이 느린 이유라면 복잡한 도메인에서 비용을 절감하려고 컴포넌트를 재사용하려고 노력해야하는 진영이 주로 Java를 쓰기 때문 아닐까?

결국 SI에서 Java를 많이 쓰기 때문… ㅠ.ㅠ

오리대마왕 : 복잡한 계층 클레스라는 뜻이 뭔지 잘 모르겠지만 자바가 다루는 객체 세상이 복잡하기 때문에 컴포넌트 구성을 책임질 무언가가 따로 있어야 한다면 맞는 말 같기도 합니다.

사실 이 글보고 하고싶은 말이 많이 있었는데, 정리가 안되서 안쓰고있다가 토비님의 글 을 보고 감동했어요.