내가 모른다고해서 잘못 만든건 아니죠..

COM도 아니고 액티브엑스도 아닌데 왜 번거롭게 인터페이스로 만들었는지 저동 궁금한데요?
클래스로 만들었다면 Tools API 접근하기 더 쉽고 편했을텐데 말이죠.

볼랜드 터보 파스칼, 델파이 1.0 처음 나왔을 때 부터, 파스칼로 잔뼈가 굵은 지인이 있어
여차저차 전후얘기 하면서 물어봤는데

그분 왈 "우아하게 보이려고" ㅎㅎㅎㅎ 정말 우아하게 보이려고 그런건지도 모르겠네요.

솔직히 국내에서 내로라 하는 파스칼 매니아 분들도 Tools API 깊게 알고 있는 분은 한명도 없을 겁니다.
저도 프로그램 개발회사 팀장이라서 파스칼로 밥 먹고 사는 분들 많이 알고 있지만 Tools API 깊게 알고있는 분은
한명도 없더라고요.

civilian 님은 왜 쉽고 편하게 클래스로 만들지 않고 인터페이스 만들었는지 혹시 이유라도 알고 게신가요?

인터페이스를 사용하면 선언과 구현이 분리되지요.
따라서 각 클래스간의 결합이 느슨하게 할 수 있고요 (클래스의 변경에 따른 영향도가 적어집니다)
Object Pascal에서 지원하지 않는 다중상속을 해결하기 위해서라도 필수적인 부분이라 생각됩니다.

IDE의 많은 부분이 Object Pascal로 구현되어 있지만, 일부 기능은 .NET을 사용하기도 합니다.
이런 경우 순수 Object Pascal로만 IDE를 구현한다면 어려움이 많겠지요.


저 역시 완벽하게 ToolsAPI를 이해하지는 못하지만,
이를 이용해서 단순 반복작업을 줄여주는 위저드를 만들어서 사용합니다.

저도 취지는 잘 모르겠습니다.
그냥 가능성만 생각하자면 델파이의 interface가 COM지원이 가능하게 됐다고는 하지만 단지 COM 계열만을 위한 기능은 아니라 생각합니다.
오히려 넓게 생각하면 java의 interface와 취지가 비슷하다고 보면 되지 않을런지.

추상메소드로 어지간한 상황을 때울 수 있지만... 안그럴때도 분명히 있거덩요.
A -> B -> C 로 상속되어가는 객체가 있다고 합시다.
이 녀석을 D 라는 함수에 인자로 전달하고 싶은데... 이 함수가 뜬금없이
E -> F -> G 으로 상속된 객체의 기능중 하나를 원하는 경우.

이 때 다시 A + E 를 만족하는 H 라는 객체를 설계하는 것 보다는
I 라는 형식을 정의하고 A와 E가 따르도록 하는게 편하죠.
함수 D에는 I , 즉 인터페이스의 인스턴스를 인자로 전달하고 말이죠.

동일한 개념이 오브젝티브-C에도 있습니다. 프로토콜이라고 부르지요.
다른 객체가 던지는 "메시지"에 반응하기 위해 기존에 정의된 약속을 맞춰주는 개념입죠.
자바는 아예 인터페이스라는 명칭까지도 동일합니다.
C++은 원래부터 다중상속이 되는 물건이니 이런 개념에 얼마든지 대응할 수 있고...
당연한 얘기지만 ActiveX를 위해 그런걸 만들어두지는 않았지요.

오브젝트 파스칼에 인터페이스가 도입된게 정확히 언제인지는... 역사에 약해 잘 모르겠습니다.
이런 정보는 사악신님이 딱인데... 지금 놀러가보니 인터페이스에 대한 좋은 글도 적어두셨네요.
http://saksin.tistory.com/958
제가 처음 본 건 델파이 3이었는데... 아마 대충 맞을껍니다.

여담으로 델파이+액티브엑스에 관한 재미난 이야기가 "Delphi COM Programming" 서문에 나와요.
http://www.amazon.com/Delphi-COM-Programming-Eric-Harmon/dp/1578702216
이 책의 저자인 에릭 하몬은 1995년 한 세미나에서 "델파이 2"를 사용해
1400명의 개발자들 앞에서 (덜덜 떨면서) 한시간 가량 2,500줄짜리 ActiveX 예제를 만들어
델파이 버튼을 비베 4폼에 올리는 방법을 시연했다고 회고합니다.
그 덕에 엔더스 해즐버그에게 낚여 DAX팀에 참가하게 되었다네요.
그렇게 태어난 델파이 3의 ActiveX 지원은 지금 떠올려도 충격과 공포...

인터페이스를 슬쩍 들여다보며 내린 결론은...
COM과 ActiveX를 위해 인터페이스를 만들어낸게 아니고,
델파이에서 COM과 ActiveX 지원이 인터페이스를 이용해 구현되었다는 것.

주절주절 떠들었는데 저도 뭐라하는지 잘 모르겠네요. 암튼 써보시면 좋습니다.
인터페이스를 사용할 때 덤으로 따라오는 참조 카운트도 맛 좋구요.

달랑 한가지 기능만 하는 초 심플한 플러그인을 만들게 아니라면 인터페이스 상속쪽이 편하지 않나요 =_=a

그럭저럭 쓸만한걸 만들라면 처리해야되는 이벤트가 한두개가 아닐텐데

interface가 처음에 추가될 때는 COM 지원 목적이 강하긴 했지만, 지금까지 interface가 남아있는 이유가 COM 때문은 아닙니다.
예를 들면 XE4에서 지원하기 시작한 모바일 지원을 위한 새로운 델파이 컴파일러(NextGen)에서는 COM 지원을 배제하면서 의도적으로 WideString이 언어에서 완전히 제거했지만 interface는 그대로 있습니다. COM과 무관하게 델파이 언어 자체적으로 interface가 필요하기 때문입니다.

interface가 반드시 필요하냐, 혹은 interface 없이 델파이 개발을 할 수 있느냐 없느냐, 굳이 따지자면 필요없다고 할 분들도 적지 않겠지만 interface 없이는 꽤 곤란해지는 케이스도 적지 않습니다. project님의 지인이 ToolsAPI에서 interface를 이용하는 이유에 대해 그냥 '우아하게 보이려고'라고 답했다면 ToolsAPI를 잘 아시는 분은 아니지 않나 싶은데요.

저는 ToolsAPI를 꽤 많이 씁니다만 interface 기반이기 때문에 문제를 쉽게 해결할 수 있는 부분들이 적지 않았습니다. 가장 중요하게는 다중 상속과 구현의 가벼움이죠. 저는 오브젝트 파스칼, 델파이 언어가 기본적으로 클래스에서 다중상속을 지원하지 않는 것을 대단히 다행으로 생각하는데요. 대부분의 경우에는 그렇지만 ToolsAPI를 이용해서 플러그인을 만들 때는 다중상속이 거의 필수적으로 필요합니다.

엔지니어들은 자꾸 기술적으로만 생각하는 경향들이 있습니다.
사실 그리 어려운 문제는 아닌데요.

클래스는 OOP를 더 잘 할 수 있도록 고안된 거구요. (클래스 없어도 OOP는 할 수 있지만 있으면 더 좋고..)
인터페이스는 인터페이스를 더 잘하기 위해서 고안된 겁니다. (인터페이스 없어도 인터페이스 할 수 있지만 있으면 더 좋고..)
둘이 비슷한 모양새를 하고 있지만 목적이 다르기 때문에 다른 점이 있죠.

인터페이스라는 것은 개인과 개인 간, 팀과 팀 간의 인터페이스일 수도 있구요. (개발 프로젝트를 위해서 사용하는 경우)
운영체제와 개발자, 툴과 개발자간의 인터페이스일 수도 있구요. (API를 위해서 사용하는 경우)
언어와 언어간의 인터페이스일 수도 있습니다.

COM이 인터페이스로 되어 있는 것은 운영체제와 일반개발자간의 인터페이스를 위함이기도 하고,
VC++로 만들어진 COM과 델파이로 만들어진 빵집의 탐색기메뉴간의 인터페이스라고도 할 수 있지요.

Tools API는 델파이, C++빌더와 일반개발자만의 인터페이스입니다.
클래스를 상속,구현하는 거하고 인터페이스를 상속,구현하는 거하고는 비슷해 보이지만 의미가 완전히 다르죠.
사실.. 인터페이스를 너무 클래스처럼 비슷하게 만들어 놨다는 게 저는 좀 불만이기도합니다.

저도 남의 코드에서 인터페이스가 보이면 슬쩍 외면하곤 했는데요...
(지금은 제네릭이나 STL을 외면중... ㅋ...)
예전에 이X중님이 좋다고 막 꼬실때도 오랫동안 난 필요없어~ 했었습니다.
그러다 XML-RPC의 델파이 구현인 dxmlrpc 코드를 보고 생각을 바꿨어요.
자기만 쓰는 것이 아니고 남에게 API를 제공해야하는 상황이라면
이보다 편한 개념은 없겠구나... 싶더라구요.

"아는 만큼 보인다"라는 어른들 말씀이 진정 와닿았던 기분이랄까...
왜 C++ 매니아들이 다중상속 없다고 다른 언어를 까대는지도 그제야 이해되고...
시간나실때 한번쯤 살펴보세요. 추천~~!

편집기 쪽은 code central의 몇몇 소스를 보면 방법론적으로 만들어진 프레임웍 비스무리한게 있습니다. 저도 그 위에다 살짝 코드 편집기 IME지원 확장을 만들었죠. IDE 버전마다 버그도 많은터라 알려진 방법론을 사용하는게 젤 편하더군요;