진정한 개발자(?)의 인생이군요. DIY 정신..(응?)

ㅎㅎ 안 주무시지만 한밤 문자에는 깜딱 놀란다는. 마뉨이 무서운 분이시군요! 내조의 여왕! ^^

Bootstrapping에 가깝지만 그리 성공적이진 않습니다. 휴…

bliss 강하게 양육받고 있습니다 ㅎㅎ (밤에 죄송해요)

맞아요

시사영어가 좀 많이 그렇습니다.

예. 좀 많이 그렇네요.

Wiki의 한계는 여전히 사용자의 노력이 필요하다는 것이죠.. 보다 작은 노력을 통해 구조적으로 지식을 쌓고 공유할 수 있도록 하는게 앞으로의 과제구요… ㅎㅎ

그래서 google notebook 정도의 저작 툴과 함께 쓴다면 좋을 것 같습니다. spring note는 기능이 너무 많아서 내용 보다는 편집에 신경을 너무 쓰게 되는 듯 하고요.

팀에서 위키 대신 스프링노트를 쓰고 있습니다. 위키보다 쉽긴 하지만 programmability는 조금 부족하죠. 그래도 정보를 팀 전체가 공유할 수 있어서 좋아요.

Wiki의 가장 큰 장점이 지식을 구조적으로 증식시킬 수 있다는 것인데 아무래도 저작툴을 사용한다면 코드가 지저분해지고 파싱하기도 어려워 보다 semi-automatic한 증식이 어려워지죠..

그래도 1차 목표는 효과적인 저작툴의 제공이고 media wiki도 그쪽으로 가고 있는 듯 하더군요….

백변괴 예. 김창준님 말씀의 요지도 무슨 툴을 쓰던 공유하는 것 자체가 중요하다는 것 같습니다.

이코다 : 맞습니다. 컨텐츠를 깨끗하게 작성하는 게 중요하죠. mediawiki에서도 wysiwyg 편집기 붙이며 그 부분에 신경을 많이 쓰는 듯 합니다.

저도 아직 위키는 적응이;;ㅋㅋ안되욥;

ㅋㅋㅋㅋ 그럼 그물고기 가 열심히 공부중인데.. 그래도 응원좀 해주시라능.. ^^

ㄴ 저 같은 마이너나 그런거죠. ㅎㅎ

기술 외적인 이유로..못하고 있습니다. OTL

ㄴ 아깝네요. 외적인 이유라니…

전 어쩌다보니 요즘 주로 UI를.. tkinter와 wxPython…

다양한 이펙트가 있는 flex 로 고고씽! 해 봤자 감각이 없으면 괴물만 튀어나오더군요.

gyedo : 오호 python의 tk 바인딩이 있나보군요. wxWindow는 요즘도 많이 쓰나봐요?

오리대마왕 : 그렇지 않아도 flex쪽에 신경 좀 써보려고 합니다. (신경 쓰려는 곳은 참 많기도 하지…)

빨빤 : UI 전문가가 왜 이렇세요.

tkinter는 python 기본 배포판에 아예 포함되어 있구요, 아무래도 wxPython이 좀 더 UI가 나아서 회사 툴들을 그걸로 바꾸려고 하고 있어요.

gyedo : tcl은 버림 받은 거군요. ㅎㅎ

fupfin tcl은 버림 받았죠 :) 그래도, Pixar 렌더맨의 Maya 커넥터 MTOR에선 tcl을 써요

디자인을 백날 잘해도 개발이 못해주면 답 없어요. 없어.

빨빤 : 그러니까 저 쓰라니까요. 값 싸고 일 잘해요. (말로만…)

현/희망연봉이 있는 이력서와 포트폴리오를 보내주세요. 으하하하.

gyedo : 렌더맨은 표준으로 자리잡았나보네요. 예전에 BMRT 가지고 장난 놀 때에 좀 공부했었는데... (다 까먹....)

빨빤 : 그냥 신입으로…ㅋㅋㅋ

BMRT도 하셨었군요 :) BMRT 개발자를 Pixar가 sue해서 이제 없어져버렸죠

저런… 안타깝네요. ray tracing 공부한답시고 이것저것 좀 건드려봤었는데 BMRT는 소스가 공개되지 않아서 좀 안타까웠지요. ㅎㅎ

언급하시려던 UI 기술이 렌더맨… 이런거였군요.

ㄴ 젊을 때 깔짝거려봤을 뿐입니다. 한때 리눅스 클러스터링 기술 사용해서 3D 렌더링 대행 서비스를 해보면 어떨까 했었거든요. ㅋㅋ

fupfin ㅎㅎ그게 바로 제가 있던 벤쳐에서 하던 …

ㄴ 결과가 어뗐나요? (왠지 안 좋았을 것 같…)

ㄴ 넵 멋지게 망했지요, 자세한 이야기는 이번에 한국가서 뵙게 되면…

락스에 눈 소독하시면… 실명하실텐데 :)

ㄴ 희석 많이 해서…;;;;

젠장 ASP 사업자 끼고 처리하겠답니다. 이번 기회에 ASP 사업이나 할까?

에효 결국… 안타깝네요.

요즘 ASP 사업자가 많은가 보네요. 저도 하나 알아보고 연동해야 되는데, 아 바쁘다. 괜찮은 ASP 사업자 있으시면 소개 부탁드려요 ^^

닥치고 가입은 했는데, Grails 설치조차 안한.. Groovy & Girls 클럽은 없을까요? ㅋ

이런 시영 아저씨께서 만드신 거군요. ㅋ, 주인장이 마음에 안들어요. ^^ ㅎㅎㅎ

ㄴ 뭔가 자간에서 애증이 교차하는 듯한 느낌이 듭니다. ㅎ

자바가 더 어울리는 스타트업도 있겠죠.. ^^;

Java Startup?... Seam .. 어떠세요~?

java startup 엔 역시 EJB3… 휘유웅….

EJB3는 draft 였을 때 jboss로 잠깐 해 본 것 말곤 없네요. 요즘 많이 쓰나 모르겠어요.

ㅎㅎㅎ 스프링 전도하시는 건가요? 부흥회 하신다면 참석해서 열심히 배우고 싶습니다만… ㅋ

ㄴ 어머! 오해입니다. ㅋㅋ 저건 Grails 사용자 모임이고 스프링은 KSUG 죠. ㄱㄱㅅ

또 회장님의 지시가!! ((서둘러 가입버튼을 누르며…))

rath 님은 해커임

rath 님은 능력자

rath 는 초굇수

전설의 매트릭스 코딩

rath 님은 지름신~!

제 미친이기도 하십니다.(으쓱)

rath 님 만세 @@

rath 님 멋지시다. 나도 (내 미친이다) 하고 싶어서 어느새 친구신청을 꾹! -_-;

ㄴ 미친 소개 수수료….. (아! 기분이다. 이번에는 무료로 해드리죠.)

-_-;; 뭐라도 하나 더 만들어야할 것 같은 기분이.. 삐질삐질!; 원더풀한 소개 감사합니다. 이 글 올리셔서 친신이 3분이나 들어왔어요!

저도 무척 좋아하는 소설이네요~ ㅋㅋ

ㄴ ㅎㅎ 반갑습니다. 이것도 전산 오덕의 특징일까요? ㅋ 그런데 이사람이 실존 인물 이었네요?

전 잘 몰랐어요… 전 전산오덕 아닌거죠?!! ((왠지 전산 오덕 이미지가 아니란 말에 좋아하는…))

전 도통 무슨말인지 잘 모르겟네요;;ㅋㅋ

nephilim : 우리 모두 조금씩은 부족한 오덕이지요. 100% 완전해지는 그날까지! (피해갈 수 없습니다.) is윤군 : 아직 오덕이 아니라서 그래요. 좀 더 노력하세요. -_-

/fupfin/ 넹.. 오덕 아자 .. ;;;ㄷㄷㄷ

헉 이렇게 하는게 아닌가 ;;; 아직 미투 초보라서 ..ㅋ

닉으로 링크 걸 때는 \를 쓰셔야 해요. ㅎㅎ

자기 주장은 있지만, 절대 겸손하지 않은 1인… 무조건 이겨야 직성이 풀림.. (그런데, 이겨서 어쩌자는건가? 고객을 말이지..)

ㄴ 기술사는 그래도 되요. ㅎㅎ

404 error (응?)

ㄴ 그런 사람 없다는 뜻? ㅋㅋㅋ

아니면 그루루비 (GrooRoovy)로; 유상무상무 놀이가 생각이 나는군요;

ㄴ ((모른 척 해야겠다 -_-))

공감합니다..딱 현재의 제 상황이네요..이러지도 저러지도 못하는 상황..

무엇인가를 선택하는 일은 항상 어렵지만…. 성철형님이라면 현명한 판단하실꺼라고 믿어요 ^^

ㄴ 설마요.

회장님 어디로 가시옵니까..ㅠ_ㅠ

ㄴ 안드로메다로…;;;

이상, 멘토를 찾으시다 친히 멘토가 되신 회장님의 말씀이었습니다. 존명! ㅋ

멘토께… 존명! ㅋ (2)

-_-);;; 댓글을 닫았어야 했…

이렇게 스스로 멘토가 되신거군요…ㅎㅎ

스승님…

모수자천이라던 고사성어가… 자신이 자기를 천거하다. ㅋㅋ

스승님~~ ^^

음… 고액 과외라도 시작해볼까…;;;;

스승님~ 다크사이드 포에버~ ㅎㅎ

ㄴ 고액 과외 하시게? Sith 합격 속성 코스는 좀 비싼데…

롤 모델이 없다면 스스로가 롤 모델이 되라는 말을 누가 했더라요.. —a // 참 KSUG 회장 되신 거예요? 축하축하드려요!! ^^

Sith.. 코스…. ((그러면서 끌리는 이 감정은?? -_-;; ))

bliss 님 그말은 제 마나님께서 하셨습니다. ㅋㅋ(제 마님은 무서운 분. 약한 소리하면 얄짤 없어요.)

저런 교육이… 쭉~~ 고등학교까지 이어저야하는데… 참 아쉽죠..

애 놓으면 이사갈 생각 ㅋㅋ

헐.. 고생하셨어요… 책.. 정말 무겁죠.. ㅠ.ㅠ

ㄴ 허리 부러지는 줄 알았습니다. ㅠㅠ

느와르 건담인가요?

예 맞습니다 (제건 아니지만…) 척보시면 아시네요 ㅎㅎ

건프라도 하시나요? mg같은 전문용어 등장이 심상치 않네요ㅎㅎ

ㄴ 오해입니다. -_-

이거슨 공중전 ㅎㅎ 저 비행기는 스카이 글래스퍼이던가ㅎㅎ 기억이 잘 안나네요 ㅎㅎ

저희도 시도를 해보고 싶은데요… 이왕에 치마 입은 아가씨 피규어를 매달고… (튄다)

왜 아직 회사이신 건가요? ㅜㅜ

회의 끝나고 이제 퇴근하려고요 ㅎㅎ

오오 멋지네연

저런거 먼지는 어떻게 터나요? :)

멋진 회사군요 @@

별다방은 한 지역에 집중 투자하는것 같아요.. 없는 곳은 아예없고.. 있는 곳은 한집 걸러 하나씩 있으니;

네.. 회장님!!!

ㄴㅡ,.ㅡ); 갑지가 스폰지 밥이 생각 났… ;; 예! 선장님!

하앍 닥치고 다운입니다 +ㅂ+

예 회장님. (_ _)

DB문외한의 질문: 회장님의 지시라 다운로드 받기는 합니다만, 왜 PostgreSQL 인건가요? (( 오픈소스 DB는 derby, hsql, mysql 그냥 써서... 정말 몰라서요))

사실 대부분의 객체지향 원칙이라는 것은 정확히 말하면 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를 많이 쓰기 때문… ㅠ.ㅠ

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

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

헐… ㅠ.ㅠ

에고 이런 일도 있군요

케이블 불량 아녜요?

케이블 문제 같지 않아요. 어제 집의 LCD 모니터에 연결했을때 잠깐 인식하더니 그 후에 반응이 없었거든요. 그 뒤로는 쭉…ㅠㅠ

고장난 터치의 최종 상태. 전원 끄면 충전은 됨. 전원 켜면 충전도 싱크도 안 됨. app는 네트워크로 구매할 수 있지만 기본 app로는 새 음악과 동영상을 볼 수 없음. (이제 MP3P라고 부르지 말아주...아직도 미투질에는 최고)

논의 중간에 끼어들어서 죄송하지만, 민희님이 말씀하신것과 같이 DI라는 것이 Static Typing 언어의 영역 밖으로 나오게 되면, 이미 의미 자체가 희석된다고 생각합니다. 포괄적인 추상화개념으로 생각하신다면 그건 이미 Architectural Pattern이겠지요 :)

이 스레드 가 조금이나마 논의 진행하시는데 도움이 되었으면 하네요

DI의 대한 논의 에 끼어들 지적 능력이 안되서... 한탄 중... 닥치고 DB 설계나... 고수 분들이 너무 부럽군요. 동종 업계 까는 거 잘 안하는데 차세대 플랫폼 설계 하며 다른 회사 DB 설계 보니 IT 업계에서 날로 먹는 인간들 참 많아.

아… DI. 어쨌든 똑같지 않나.

험블 : 아우 죄송하긴요. 오히려 감사할 뿐입니다. 잘 읽어보겠습니다.

그래서 솔직히 파이썬 스프링 이런거 왜 하는지 잘 모르겠...;

다이나믹 타입 언어에서의 DI 문제 관련 글을 읽다 보면 디자인 패턴.. 아니 SOLID 같은 객체지향 원칙(그중에서도 핵심인 OCP )에 대한 고민 자체가 없는 것 아닌가 생각된다. 흥미롭게 연구해 볼 주제 같다.

이 논의가 너무 재밌습니다. Offiline으로 하고 싶은데.. ((하지만 고수님들을 넘어선 괴수님들이… -_-;))

코딩 중에 어떤 녀석이 자꾸 의존성이라고 인지되기 시작하면 (의식적이든 무의식적이든) 그때가 DI를 적용해야할 때가 아닌가 싶습니다.

중소규모 프로젝트인 경우 프로그래머 한 사람이 의존성이건 비지니스로직이건 다 책임져야하는 경우가 많으니 DI 좋아하는 사람을 이상하게 여기는 것이 자연스러운게 아닌가도 싶고요.

(( 하지만 다중이들은 DI를 좋아해요 ))

ㄴ 아항! (응?!)

쉽게 본질에 이를 수 없는 문제라면, 그것 또한 허상이 아닐까요? ^^a

ㄴ 오호. 역시 사업가다운 실용적인 말씀입니다. ㅎㅎ 그런데 6번인가 질문해서 본질적인 문제를 찾으라는 게 경영쪽에서 들은 말 같… (어디서 읽었는지 도무지 기억이… -_-);

저도 5why 라고 비슷한걸 어렴풋이 들은 기억이 ^^a

ㄴ 아! 5이군요. 숫자에 약해서… (적어놔도 어디에 적었는지 까먹고… -_-);

제가 DI 프레임워크를 제대로 써본 게 없어서 그런데 Guice 같은 걸 한번 써봐야겠어요.

그런데 궁금한 것은 왜 유독 Java 진영에서 DI, IoC를 얘기하고, 다른 언어에서는 그런 concept가 나오지 않는 걸까요? (제가 잘 몰라서 그런건가요?;)

ㄴ 저도 그게 궁금합니다. 며칠전 맹수 씨와 토론한 주제이기도 한데 아직 명확한 결론은 얻지 못했습니다. beyond java 라는 책에 ruby에 DI가 필요 없는 이유가 써 있다던데 아직 읽어보지 못했네요.

겉핥기로 살펴본 바로는 제 취향에는 XML로 설정하는 Spring IoC보다는 Annotation 등을 써서 DSL을 만든 Guice 쪽이 더 나아보이네요…

ㄴ 마틴 파울러는 자바를 넘어 모은 OO 환경에 해당 하는 원칙 이라고 했는데... .Net쪽은 반응이 느려서 그런 것 같고 다른 다이나믹 타입 쪽에서는 IoC가 필요 없는 뭔가가 있는 것 같습니다.

ㄴ Annotation이 편하지만 설정과 코드를 분리한다는 원칙은 살짝 위반한 면이 있습니다. 스프링도 2.5부터는 Annotation으로 구성할 수 있습니다. 구글 주스 덕분에 로드 존슨이 생각을 바꾸었죠.

복잡한 설정를 숨길 수 있는 점이 Java에서 DI가 유명해진 이유가 아닐까… 생각 중입니다.. ^^ 지금막

다른 언어에서 차용되지 않는 이유는 Cohesion을 낮추는 OO적 진화 과정에서 비교적 최근에 나왔고, "어따 적용하면 딱이다" 하는 분야가 다른 이들이 보기엔 아직 명확하지 못하기 때문이 아닐까 합니다.

사실 저도 항상 궁금한 건데, 이런 멋진 질문을 올리고 답하는 모습이 너무 반갑다는… (( fupfin 회장님~ DI를 사사하여 주십시요. OTL ))

nephilim : 저도 보급 속도의 문제라고 생각합니다. 사실 자바쪽에서도 DI가 메인스트림이 된 건 최근의 일이니까요. 그리고 어찌 저에게 가르침을 청하십니까 오히려 배워야 하는 걸요.

뛰어서 탄 버스타고 부평 갔다 온 저를 생각하시면 위로가 될 듯..ㅎㅎ

생각 없이 뛰면 그런 일이 있겠네요. 하긴 나도 비슷한 일이 여러번… -_-);;

에…. 그렇쿤요!!!

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

원래 아끼셨겠지만, X장님이.. 되시고서는 스프링을 더욱 전략적으로 미시는데요? ㅎㅎ

ㄴ 눈치 채셨? -_-

Python으로 구현한 IoC를 보면 정말 파이써닉하지 못하다는 생각이 마구마구 듭니다;;;;;

Spring은 Java로 작성되었을 때 가장 아름다울듯

Spring으로 대동단결!!! 인건가요?

홍민희 : 제가 궁금해하던 부분인데 Python 다운 IOC라면 어떤 것이 될까요? 저도 Java 디자인을 그대로 가져가는 건 아니라고 보는데… DSL로 설정?

그러게요. 일단 XML 설정은 완전 에러!;;

ㄴ 그죠. Xml은 넌센스…

이제 곧 Spring 못하는 사람은 집에 가야하나요? 주변에 모두 '통~ 통~' 스프링이라고 하시네요. ㅋ

ㄴ 꼭 스프링을 써야 하는 건 아니겠지만 IoC 컨테이너는 재사용과 유연성 측면에서 참 유용한 것 같습니다.

Spring을 일단 적용하면, 다른 게 눈에 안들어옵니다. EJB 따윗… 훗!

ㄴ EJB가 뭐에요? (핫! 이러다 EJB 3를 앞세운 제국의 역습에 당할수도!)

DI말고 DI가 해결하는 문제를 해결하는 방법에는 무엇무엇이 있을까요?

오, 이제 나도 Spring 써보는 건가...