성현 님이 쓰신 글 :
: 본인은 C++ 빌더를 주로 씁니다
: 가끔 Tools API를 사용하면 좋겠다는 생각을 하다가도
: IDesignWindow, IDesignNotification, IEditHandler, IActivatable 등등
: 인터페이스로 만들어 놓아서 사용하려면 골치만 아프고 되게 깝깝하네요
:
: ActiveX도 아니고 그렇다고 COM 도 아니면서 뭐하러 이딴 식으로 Toools API를
: 만들어놨는지 이해가 안되네요. 쩝
:
:


COM Interface 방식을 안쓰고 일반적인 방식으로 구현하려고 해도, 델파이 파스칼 랭귀지는
class multiple inheritence 를 근본적으로 언어차원에서 지원하지 않기 때문에 Interface 방식을
사용할 수 밖에 없음.

클래스 다중 상속을 지원하지 않는 언어에서 Interface 방식은 사실상 언어의 한계를 우회하기
위한 방법으로 많이 쓰임. C# 또한 그렇고.

또한 Interface 를 이용하면

class CSomeServiceProvider : IInterfaceA, IInterfaceB, IInterfaceC
{
             .....
};

HRESULT STDMETHODCALLTYPE QueryInterface( REFIID riid, VOID **ppvInterface)
    {
        if (IID_IUnknown == riid)
        {
            AddRef();
            *ppvInterface = (IUnknown*)this;
        }
        else if (__uuidof(IID_IInterfaceA) == riid)
        {
            AddRef();
            *ppvInterface = (IInterfaceA*)this;
        }
        else if (__uuidof(IID_IInterfaceB) == riid)
        {
            AddRef();
            *ppvInterface = (IInterfaceB*)this;
        .,..
}
클라이언트에서 CSomeServiceProvider 객체 하나를 통해서 객체를 캐스트 하는 것만으로도
필요한 인터페이스를 취할 수 있기 때문에(같은 this 포인터 이기 때문에) 사용하기 편리한
잇점이 되고, 이건 COM이 갖는 장점이기도 함.

사족으로 엠바가 닷넷을 포기하지 못하고, 또 툴을 설치하면 필연적으로 닷넷 설치 과정이 따르게 되는데

이건 근본적으로 엠바가 프로젝트 빌드시스템으로 MS사의 Build Engine을 사용하고 있기 때문임.
MS사의 빌드엔진 자체가 닷넷으로 구현되어 있음. 그래서 필연적으로 닷넷을 설치할수 밖에 없음.

엠바가 자사의 Make를 통한 빌드시스템을 포기하고 MS사의 빌드엔진을 선택한 이유는 MS사의 빌드엔진이 빠르기 때문임.
하나의 소스를 다시 컴파일해야 할지 아닐지를 판단하기 위해선 디펜던시로 걸리는 수백 수천개의 헤더파일들 중에서 하나라도
변경된게 있는지 없는지 사전에 체크해야 할 필요가 있는데, 기존의 방식은 시스템 API를 매번 호출해서 파일 변경여부를 확인하는
방식이라 느렸지만

MS사의 빌드시스템은 파일 관련한 API들을 후킹하고 있어서, 파일 변경여부를 체크하기 위해 반복적으로 API를 호출할 필요 없이
사전 탐지가 가능하기 때문에 빌드 속도가 매우 빨라서, 엠바에서도 오래전 부터 MS사의 빌드엔진을 채택하게 된 것임.
우리 엠바는 MS사의 빌드엔진 사용하면서 빌드속도 빨라졌어요 라고 광고하면서 ㅋ

엠바 IDE는 껍데기에 불과하고 디펜던시 체크, 컴파일, 리빌드 그런 과정은 MS빌드 엔진에 의해서 이루어지게 됨.