에릭감마 같은 초고수가 인터페이스 이름 뒤에 1,2 숫자나 붙이고 있을 수 밖에 없는 상황이라니...

오호 에릭감마가 어디서 그러고 있어요? +_+ 설마 1,2 안 부치고 One,Two...;;;

전 반대로 생각했습니다. 정의된 interface를 변경하지 않는 것은 사용하는 측을 배려하기 위함으로 보입니다. 제가 해석하기로 본문 중 2,3 으로 숫자가 붙은 것은 원래 interface 쓰는 client module이 안심하고 사용하기 위함이지, 언어적 한계때문에 우회한 방법이라고 보이진 않네요.

맹수 : 이클립스 맹글면서 그러고 있다잖아. 언어가 이러니 저러니 투덜 거리는 것도 사실 바보 같은 짓이기는 하지. 솔직히 난 아직도 internal과 public도 구별 못하는 수준인데...

일단 publish 된 interface 의 경우 변경하지 않는 것이 cilent 의 상호 연동을 보장하기 위한 방안이라고 생각합니다. 확장이야 모르겠지만, interface가 변경되어 버리면 그에 의존하던 기존 코드들은 다 동작을 못하겠죠. 감마옹도 그래서 일부러 2,3을 붙이더라도 기존것을 유지하려고 애쓴 것이 아닐까요

오리대마왕 : 그게 메소를 변경하는 문제라면 말씀이 맞는데요. 단순히 몇가지 메소드를 추가하는 것 조차 안되니 말이죠. 저 글에서도 이런 특성 때문에 interface 대신 추상 클래스가 유용한 경우도 있다고 하네요. 켄트백의 구현패턴에서도 같은 얘기가 있고요. 하지만 추상 클래스는 다중 상속 문제 때문에 한계가...;;;

메소->메소드 입니다. (또 오타... -_-);

아, "확장"에 국한해서 말씀하시는 것이라면 그렇겠네요. 전 "확장"이라는 표현을 "확장" 해서 "변경" 까지 언급하시는 것으로 잘못 이해했습니다. ^^

켄트백의 구현 패턴에 보면 version interface pattern이 있는데 이 것이 이런 자바의 제한 때문에 생긴 패턴이죠. 그런데 다른 언어에서는 인터페이스를 써본 적이 없어서 어떤지 모르겠네요.

오리대마왕 님 : 다시 읽어보니 제가 좀 오해하게 썼네요. ㅎㅎ 죄송...

하긴 자바 처음 설계할 때에 누가 인터페이스가 이렇게 성공할 줄 알았겠어.

ㅋㅋㅋ 그런데 확장까지 가능한 어떤 새로운 방법이 있다면, 어떤 것일까요? 흠, 그건 programming langauge 개발자가 알아서 할 일인가..

자바의 경우 프레임워크 클래스에 메소드가 추가 되었다고 해도 그 클래스를 가져다 쓰는 놈은 다시 컴파일 할 필요 없이 그냥 바이너리 상태에서 돌릴 수 있는데 인터페이스의 경우는 인터페이스에 어떤 변형(단순한 확장)만 있어도 다시 컴파일 해야만 하거든요. 어떤 특별한 기술 문제가 아니라 언어의 특성일 뿐이에요. (물론 제가 이해 못하는 언어학적인 이유가 있을지도 모르겠지만... -_-);'

사실 버젼의 문제라면 인터페이스의 문제라고 하기 보다는 모듈이나 컨포넌트에서 하는게 맞지 않나 싶은데요. 펄이나 루비처럼 모듈에 버젼기능을 추가한다거나.

이제 슬슬 기억이 안나는데.. 인터페이스끼리는 mixin 혹은 다중상속등이 안되나요? --;

OSGI 같은 것을 사용해서 버전 관리를 한다고 해도 Interface가 변경되면 다시 컴파일 해야 하는 문제는 여전히 존재. SOAP, REST 같은 비 Java 기술을 사용해서 컴포넌트끼리 연동하지 않는 한 Interface 문제는 계속 남을 수 밖에 없지 않을까?

맹수 : 너무 다양한 언어를 하다보니 혼돈이 오고 있는 거야. -_-;

솔직히 다시 컴파일 하는게 왜 문제인지 모르겠어요. 객체처럼 작은 단위들 안해서 굳이 그런 재컴파일 없는 동적인 부분이 필요한지.

Subinterfaces은 여러개 되는 군요. 흠.

그냥 내가 만드는 프로그램 내에서라면 문제가 없지. 그런데 프레임워크나 기타 API를 만드는 경우라면 내가 만든 모듈을 누가 얼마나 쓰고 있는지 알 수 없는 상황이 되고 인터페이스 변경으로 하위 호환성이 안되는 일이 생겨 버리는 것이 문제.

대규모로 설계해 본적은 없지만.. 결국 변화를 줄때 변하지는 않는 축을 결정하고 그 축 중심으로 변화하라.라는 객채마법사들의 주문들이니까. 명시적으로 프로토콜을 만들든지. 덕타입으로 각각 책임을 할당하듯. 또 다형성 확득의 차원에서 계약 자체의 변화에 너무 많은 기능도 좀 아니지 않을까. .

해서요... 그리고 사실 그런 프레임워크나 라이브러리의 API의 변화는 자바이든지 루비이든지. deprecated 하는 정책 말고 본적이 없어서요. (..)

그런데 별도 지시어라고 하니까 DesignByContract가 생각 나는 군요.. DuckType에 DByC을 부치는게 이득일까요? StrongType이 더 이득일까요?

계약과 인터페이스

내가 문제 삼는 것은 너무 '많은 변화'가 아닌 어떤 변화(단순한 메소드 추가)도 허용하지 않는 경직성이고 만약 계약 때문이었다면 interface 선언할 때에 final 같은 지시자를 두도록 하는 방법을 쓸 수 있었다고 생각해. 그리고 설계를 뒤로 미루는 Agile과 자바가 친해지기 어렵게 만드는 이유가 되기도 하고...

Strong Type을 Design by contract라고 하기에는 좀 그렇지 않나? ㅎㅎ 그런데 DByC는 뭐여?

JAVA, 잡아, 자 봐...

DByC DesingByContract 인가보네요.

전 제가 뭘 배포해서 남들이 가져다 쓴적이 없어서. --;

아 항! DByC가 그거…(바보 아냐. -_-) 솔직히 Duck Type의 단점을 DByC(바로 써먹..)로 해결하는 것은 너무 무거운 느낌이고 dynamic type, static type, DByC 모두를 제공하는 것이 좋지 않을까? Scala의 compund type도 실용적인 것 같고…

ucandoit 님 : 예 낮잠 좀 자보도록 하겠습니다. ㅋㅋ

멋지시군요. 다 자바를 사랑하기에 하시는 고민인듯.. 자바의 문제는 자바를 사용하는 대부분이 자바를 사랑하지 않는다는데 있지 않겠습니까?

아~ 나는 말한마디 섞지도 못하능구나…..(저는 설계보다는 구현에 중점을…..실은 구현하기도 바쁘다능 캬캬캬) [ 글보러가기 ]

잘 모르니까 이렇게 말이 많은거죠. 구현하다보면 길을 잃고 뱅뱅 도는 일이 일상다반사에요. -_-