2011-07-29 20 views
5

Estoy trabajando en Windows. Tengo que ver cierto conjunto de API para Windows 2008 y superior y un conjunto diferente de API para otros sabores de Windows. Quiero saber cuál es la mejor manera de diseñar este tipo de cosas, así que mi código principal conductor no tiene #ifdefplataforma de patrón de diseño C++ api

Por ejemplo: En Windows 2008 Tenemos API

EVT_HANDLE WINAPI EvtOpenLog(
    __in EVT_HANDLE Session, 
    __in LPCWSTR Path, 
    __in DWORD Flags 
); 

y para Windows 2003 tenemos otra API que hace lo mismo.

HANDLE OpenEventLog(
    __in LPCTSTR lpUNCServerName, 
    __in LPCTSTR lpSourceName 
); 

Lo que estoy buscando es tener algún tipo de API contenedora en mi código que maneja internamente estas llamadas.

+0

¿Está diciendo que quiere que su código de controlador principal use la misma API de alto nivel, independientemente de la API dependiente del sabor subyacente? –

+0

tal vez el GUIFactory en el libro de patrones de diseño. ¿Puedes dar algunos ejemplos de qué apis y cómo difieren? –

Respuesta

6

Puede escribir Capa de abstracción de plataforma, que expondrá una interfaz común para todos los tipos de API y para cada puerto, luego puede implementar la interfaz. Puede proporcionar la abstracción como una biblioteca separada para cada puerto, lo que garantiza que su aplicación de llamada sea la misma que la biblioteca a la que se vincularán los cambios.

+0

Básicamente este es el camino a seguir. Hay dos formas de implementarlo, use una clase separada para cada plataforma que siga una interfaz común o use una Fachada que tenga todos los ifdefs en el código. En el segundo caso, no necesita una clase y solo puede tener la función independiente. – rioki

0

Un enfoque sería tener una interfaz en un encabezado que no cambie y tener .cpp por separado para cada plataforma que requiera. Luego compila solo el .cpp que necesita para una plataforma determinada.

Un segundo enfoque es tener una única interfaz de clase base que no cambie y tener subclases que modifiquen el código según sea necesario a través de funciones virtuales, pero no recomiendo este enfoque.

Sin embargo, otro enfoque sería utilizar algo así como el modismo PIMPL (puntero a la implementación). Este enfoque permitirá que su interfaz de encabezado nunca cambie y también ocultará todos los datos específicos de la plataforma en una implementación de clase privada. Here's a semi-decent article on this design pattern.