2011-07-29 15 views
5

मैं विंडोज पर काम कर रहा हूं। मुझे विंडोज 2008 के लिए एपीआई के कुछ सेट और विंडोज के अन्य स्वादों के लिए उपरोक्त और एपीआई के अलग सेट को देखना होगा। मुझे पता है कि सामान इस तरह डिजाइन करने के लिए सबसे अच्छा तरीका क्या है, ताकि अपने मुख्य चालक कोड #ifdefसी ++ डिज़ाइन पैटर्न प्लेटफ़ॉर्म विशिष्ट एपीआई

उदाहरण के लिए है नहीं करना चाहती: विंडोज 2008 में हम एपीआई

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

और Windows के लिए है 2003 हमारे पास एक और एपीआई है जो वही करता है।

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

जो मैं ढूंढ रहा हूं वह मेरे कोड में कुछ प्रकार का रैपर एपीआई है जो इन कॉलों को आंतरिक रूप से संभालता है।

+0

क्या आप कह रहे हैं कि आप अंतर्निहित स्वाद-निर्भर एपीआई के बावजूद अपने मुख्य ड्राइवर कोड को एक ही उच्च स्तरीय एपीआई का उपयोग करना चाहते हैं? –

+0

शायद डिजाइन पैटर्न पुस्तक में GUIFactory। क्या आप कुछ उदाहरण दे सकते हैं कि कौन से एपिस और अलग कैसे हैं? –

उत्तर

6

आप प्लेटफार्म एब्स्ट्रक्शन लेयर लिख सकते हैं, जो सभी एपीआई प्रकारों के लिए एक आम इंटरफ़ेस का पर्दाफाश करेगा और प्रत्येक पोर्ट के लिए आप इंटरफ़ेस को कार्यान्वित कर सकते हैं। आप प्रत्येक बंदरगाह के लिए एक अलग पुस्तकालय के रूप में अमूर्तता प्रदान कर सकते हैं जो सुनिश्चित करता है कि आपका कॉलिंग एप्लिकेशन केवल लाइब्रेरी से जुड़े परिवर्तनों के लिए ही रहता है।

+0

असल में यह जाने का रास्ता है। इसे कार्यान्वित करने के दो तरीके हैं, या तो एक सामान्य इंटरफ़ेस का पालन करने वाले प्रत्येक प्लेटफॉर्म के लिए एक अलग श्रेणी का उपयोग करें या आप एक फेकाडे का उपयोग करें जिसमें कोड में सभी ifdefs हैं। दूसरे मामले में आपको कक्षा की आवश्यकता नहीं है और केवल कार्य ही अकेले खड़े हो सकते हैं। – rioki

0

एक दृष्टिकोण में ऐसे शीर्षलेख में एक इंटरफ़ेस होना चाहिए जो बदलता नहीं है और आपके लिए आवश्यक प्रत्येक प्लेटफॉर्म के लिए अलग .cpp है। फिर आप केवल उस .cpp को संकलित करते हैं जिसे आपको किसी दिए गए प्लेटफ़ॉर्म के लिए आवश्यक है।

एक दूसरा दृष्टिकोण एक एकल बेस क्लास इंटरफ़ेस होना है जो परिवर्तित नहीं होता है और वर्चुअल फ़ंक्शंस के माध्यम से आवश्यक कोड को संशोधित करने वाले उप-वर्ग हैं, लेकिन मैं इस दृष्टिकोण की अनुशंसा नहीं करता हूं।

फिर भी एक और दृष्टिकोण PIMPL (कार्यान्वयन के लिए सूचक) idiom जैसे कुछ का उपयोग करना होगा। यह दृष्टिकोण आपके हेडर इंटरफ़ेस को कभी भी बदलने की अनुमति नहीं देगा और निजी वर्ग कार्यान्वयन में सभी प्लेटफ़ॉर्म-विशिष्ट डेटा को भी छिपाएगा। Here's a semi-decent article on this design pattern

संबंधित मुद्दे