개체의 인터페이스에 대한 초기 포인터가 있으면 COM에는 개체가 다른 특정 인터페이스를 지원하는지 여부를 확인하는 매우 간단한 메커니즘과 개체에 대한 포인터를 가져오는 메커니즘이 있습니다. 개체의 인터페이스에 대한 초기 포인터를 가져오는 방법에 대한 자세한 내용은 개체대한 포인터 가져오기를 참조하세요. 이 메커니즘은 IUnknown 인터페이스의 QueryInterface 메서드입니다. 개체가 요청된 인터페이스를 지원하는 경우 메서드는 해당 인터페이스에 대한 포인터를 반환해야 합니다. 이렇게 하면 개체가 지원하는 인터페이스를 자유롭게 탐색할 수 있습니다. QueryInterface 협상이 성공하면 "지정된 계약을 지원합니까?" 요청을 해당 계약의 고성능 사용과 분리합니다.
클라이언트가 처음에 개체에 대한 액세스 권한을 얻게 되면, 해당 클라이언트는 최소한 개체 수명을 제어하기 위해 사용하는 가장 기본적인 인터페이스인 IUnknown 인터페이스 포인터를 수신합니다. 이를 통해 클라이언트는 개체 사용을 완료했음을 알리고 QueryInterface을 호출할 수 있습니다. 클라이언트는 관리되는 각 개체에 일부 작업을 수행하도록 요청하도록 프로그래밍되지만 IUnknown 인터페이스에는 해당 작업에 대한 함수가 없습니다. 대신 이러한 작업은 다른 인터페이스를 통해 표현됩니다. 따라서 클라이언트는 해당 인터페이스에 대한 개체와 협상하도록 프로그래밍됩니다. 특히 클라이언트는 QueryInterface 호출하여 클라이언트가 원하는 작업을 호출할 수 있는 인터페이스를 개체에 요청합니다.
개체는 queryInterface구현하므로 요청을 수락하거나 거부할 수 있습니다. 개체가 클라이언트의 요청을 수락하면 QueryInterface 요청된 인터페이스에 대한 새 포인터를 클라이언트에 반환합니다. 해당 인터페이스 포인터를 통해 클라이언트는 해당 인터페이스의 메서드에 액세스할 수 있습니다. 반면에 개체가 클라이언트의 요청을 거부하는 경우 queryInterface null 포인터(오류)를 반환하고 클라이언트에 원하는 함수를 호출할 포인터가 없습니다. 이 경우 클라이언트는 해당 가능성을 정상적으로 처리해야 합니다. 예를 들어 클라이언트에 개체의 인터페이스 A에 대한 포인터가 있고 인터페이스 B 및 C를 요청한다고 가정합니다. 또한 개체가 인터페이스 B를 지원하지만 인터페이스 C는 지원하지 않는다고 가정합니다. 그 결과 개체는 B에 대한 포인터를 반환하고 C가 지원되지 않는다고 보고합니다.
핵심은 개체가 QueryInterface호출을 거부하는 경우 클라이언트가 요청된 인터페이스를 통해 표현된 작업을 수행하도록 개체에 요청하는 것은 불가능하다는 것입니다. 클라이언트에는 해당 인터페이스에서 메서드를 호출하는 인터페이스 포인터가 있어야 합니다. 개체가 요청된 포인터 제공을 거부할 경우, 클라이언트는 해당 개체에서 수행하려던 작업을 포기하거나 덜 강력한 다른 인터페이스로 대체할 수 있는 준비를 해야 합니다. COM 기능의 이 기능은 해당 함수를 호출할 때까지 함수가 작동하는지 여부를 알 수 없는 다른 개체 지향 시스템과 비교하여 잘 작동하며, 그 후에도 오류 처리가 불확실합니다. QueryInterface 메서드를 호출하기 전에 개체가 인터페이스를 지원하는지 여부를 알 수 있는 안정적이고 일관된 방법을 제공합니다.
또한 QueryInterface 메서드는 개체가 지정된 계약을 지원하지 않음을 나타내는 강력하고 신뢰할 수 있는 방법을 제공합니다. 즉, QueryInterface 호출에서 "새" 인터페이스(예: 이전 개체가 배송된 후 발명된 인터페이스)를 지원하는지 여부를 "이전" 개체에 요청하는 경우 이전 개체는 충돌을 일으키지 않고 안정적으로 "아니요"라고 대답합니다. 이를 지원하는 기술은 IID가 할당되는 알고리즘입니다. 이는 작은 지점처럼 보일 수 있지만 시스템의 전반적인 아키텍처에 매우 중요하며, 새로운 기능에 대한 레거시 요소를 조회하는 기능은 놀랍게도 대부분의 다른 개체 아키텍처에 없는 기능입니다.
관련 항목
-
IUnknown 사용 및 구현