घटकों और इंटरफेस के बारे में

प्रविष्टि

हाल ही में, मैं अक्सर ऐसी स्थिति का सामना करता हूं, जहां मुझे सिस्टम को घटकों में विभाजित करने की आवश्यकता के डेवलपर्स द्वारा समझ की कमी से निपटना पड़ता है। और अगर यह समझ मौजूद है, तो घटक के कार्यान्वयन को छिपाने की गलतफहमी का पता चलता है। और इंटरफेस की सुविधा के बारे में बात करने की कोई जरूरत नहीं है।

इसके बाद, हम एक प्रक्रिया के कुछ हिस्सों के अर्थ में घटकों का मतलब है। घटक जो अलग-अलग प्रक्रियाएं या सेवाएं हैं जो आरपीसी या कुछ और के माध्यम से काम करती हैं, यहां पर विचार नहीं किया गया है। हालांकि बहुत हद तक निम्नलिखित उन पर लागू होता है।

एक उदाहरण:
मुझे किसी अन्य विभाग में लंबे समय से विकसित और परीक्षण किए गए घटक की आवश्यकता है। मैं डेवलपर के पास जाता हूं। संवाद स्थापित किया गया है:
"मुझे यह चीज़ चाहिए।" मैं इसे अपने प्रोजेक्ट में कैसे उपयोग करूं?
- हां, यहां इस लेबल पर सीवीएस से प्रोजेक्ट को भरना आवश्यक है। संकलित। आपको एक परिवाद मिलता है, और अब आपको इसके साथ लिंक करने की आवश्यकता है।
- ठीक है, धन्यवाद।
परियोजना को परिभाषित करें। Campiglio। त्रुटियों का एक समूह क्रॉल करता है, इसमें कोई भी पर्याप्त नहीं है। आप पता लगाना शुरू करें। यह पता चला है कि एक परियोजना बनाने के लिए आपको सीवीएस से परियोजनाओं का एक गुच्छा पंप करना होगा, और उन्हें भी इकट्ठा करना होगा। कुछ को स्टूडियो द्वारा मानक के रूप में बनाया गया है, कुछ एक टैम्बोरिन के साथ, जैसे ऑटोकॉन्फ़, मेक, और अन्य उनके जैसे हैं। वह सब है। यह एकत्र हुए। लिंकिंग समस्याएं शुरू होती हैं। एक, दूसरे, तीसरे जुड़े नहीं हैं। थर्ड-पार्टी लाइब्रेरी पर्याप्त नहीं हैं। परिणामस्वरूप - अनुत्पादक श्रम और प्रयुक्त पुस्तकालयों, तृतीय-पक्ष घटकों और प्रौद्योगिकियों की समझ पर बहुत अधिक समय खो दिया है।


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

उदाहरण तीन:
"मुझे यह चीज़ चाहिए।" मैं इसे अपने प्रोजेक्ट में कैसे उपयोग करूं?
- हां, यहां एक लिबा है, और यहां इसके साथ लिंक करना आवश्यक है।
- ठीक है, धन्यवाद।
आप लिब को कनेक्ट करते हैं, लेकिन यह लिंक नहीं करता है, पर्याप्त वर्ण नहीं हैं। एक बार फिर, घटकों की खोज और संयोजन जिस पर यह निर्भर करता है शुरू होता है।

उभरती हुई समस्याएं:
1. एकत्र नहीं किया गया था जो परीक्षण किया गया था। और सामान्य तौर पर, यह मायने नहीं रखता कि घटक का परीक्षण किया गया है या नहीं, पुनर्निर्माण के बाद भी इसे अभी भी परीक्षण करने की आवश्यकता है।
2. पुस्तकालयों के गलत संस्करणों के साथ इकट्ठे हुए।
3. तीसरे पक्ष के घटकों के गलत संस्करणों के साथ इकट्ठे हुए।
4. गलत विकल्पों के साथ इकट्ठे हुए।
5. जो मैंने चाहा था, बस उसे एकत्र नहीं किया।
और जिस चीज की जरूरत थी, वह सिर्फ एक कक्षा की एक विधि थी ... वह तेजी से लिखी होती।

बुराई कहाँ से आती है

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

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

आइए, मेरे दृष्टिकोण से, घटक डिजाइन को सही देखें।

उदाहरण C ++ में होंगे।

घटक कैसा दिखना चाहिए

मेरी विनम्र राय में, घटक को किट में एक हेडर फाइल के साथ एक डायनेमिक लाइब्रेरी होनी चाहिए, जिसमें घटक द्वारा लागू किए गए इंटरफेस का वर्णन होता है (यह सोचकर कि पत्थर उड़ जाएंगे, मैं आपको सूचित करूंगा कि मुझे dll-hell के बारे में पता है, लेकिन यह ठीक से डिज़ाइन और इंस्टॉल किए गए सिस्टम में मौजूद नहीं होगा)। आप यहां .def और .lib फ़ाइलों को जोड़ सकते हैं, स्थिति के आधार पर, लेकिन .dll (.so) और .h ठीक से डिज़ाइन किए गए घटक में पर्याप्त हैं। यह भी वांछनीय है कि हमारे गतिशील पुस्तकालय को स्टैटिक लाइब्रेरियों से सांख्यिकीय रूप से जोड़ा जाए। यह हमें विंडोज के तहत विभिन्न Redistributable संकुल की परेशानी से बचाएगा।

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

इंटरफेस

उदाहरण और समाधान पर विचार करें।
हम स्थिर पुस्तकालयों और इंटरफेस पर विचार नहीं करेंगे, हम तुरंत गतिशील लोगों को पास करेंगे।
खराब इंटरफ़ेस विकल्प:

#include <string> #ifdef EXPORTS #define API __declspec( dllexport ) #else #define API __declspec( dllimport ) #endif class API Component { public: const std::string& GetString() const; private: std::string m_sString; }; 

यहाँ क्या गलत है? खैर, सबसे पहले, कार्यान्वयन छिपा नहीं है। हम कक्षा के एक सदस्य को देखते हैं, हम एक तृतीय-पक्ष कंटेनर देखते हैं, इस मामले में std :: string। यानी हम कार्यान्वयन का हिस्सा देखते हैं, और यह खराब है। कोई व्यक्ति आक्रोश में आकर कहेगा कि यह मानक कंटेनर है तो वह किस तरह का है? और यह तृतीय-पक्ष है क्योंकि घटक Microsoft STL कार्यान्वयन का उपयोग कर सकता है, और हम STLPort चाहते हैं। और फिर हम कभी भी इस तरह के घटक का उपयोग करने में सक्षम नहीं होंगे। दूसरी बात: इंटरफ़ेस क्रॉस-प्लेटफ़ॉर्म नहीं है। __Declspec निर्देश सभी संकलक में उपलब्ध नहीं हैं। तीसरा: इस तरह के एक इंटरफ़ेस के साथ एक घटक के लिए एक स्पष्ट लिंक का उपयोग करना, इसे हल्के ढंग से, मुश्किल से डालना है।

पहली समस्या को हल करने के लिए, PIMPL मुहावरे और बाहरी कंटेनरों की अस्वीकृति उन्हें अंतर्निहित प्रकारों के साथ बदलने के लिए उपयुक्त है। दूसरे को हल करने के लिए, हम परिभाषित निर्देशों का विस्तार करते हैं।

 #ifdef WIN32 #ifdef EXPORTS #define API __declspec( dllexport ) #else #define API __declspec( dllimport ) #endif #else #define API #endif class ComponentImpl; class API Component { public: const char* GetString() const; private: ComponentImpl* m_pImpl; }; 

कार्यान्वयन छिपा हुआ था, क्रॉस-प्लेटफॉर्म जोड़ा गया। वास्तव में, मानक कंटेनरों को नहीं छोड़ा जा सकता है अगर विकास में एसटीएल कार्यान्वयन का उपयोग सख्ती से विनियमित हो। हालाँकि, मिश्रित सिस्टम का उपयोग करने से समस्याएँ हो सकती हैं।

स्पष्ट लिंकिंग की सादगी के साथ क्या करना है?

ऐसा करने के लिए, अमूर्त वर्ग और एक फैक्ट्री फ़ंक्शन का उपयोग करें।

 #ifdef WIN32 #ifdef EXPORTS #define API __declspec( dllexport ) #else #define API __declspec( dllimport ) #endif #else #define API #endif class Component; extern "C" API Container* GetComponent(); class Component { public: virtual ~Component() {} virtual const char* GetString() const = 0; }; 

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

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

 #ifdef WIN32 #ifdef EXPORTS #define API __declspec( dllexport ) #else #define API __declspec( dllimport ) #endif #else #define API #endif class Factory; extern "C" API Factory* GetFactory(); class Component; class Component1; class Factory { public: virtual ~Factory() {} virtual Component* GetComponent() = 0; virtual Component1* GetComponent1() = 0; }; class Component { public: virtual ~Component() {} virtual const char* GetString() const = 0; }; class Component1 { public: virtual ~Component1() {} virtual const char* GetString() const = 0; }; 

खैर, एक एरोबेटिक्स के रूप में, आप COM विचारधारा से कुछ चार्ज कर सकते हैं, जो आपको घटक की कार्यक्षमता को असीमित रूप से विस्तारित करने की अनुमति देगा, जबकि पहले से ही काम कर रहे सिस्टम के साथ पूर्ण पिछड़ी संगतता बनाए रखना।

 #ifdef WIN32 #ifdef EXPORTS #define API __declspec( dllexport ) #else #define API __declspec( dllimport ) #endif #else #define API #endif class Factory; extern "C" API Factory* GetFactory(); class Base { public: virtual ~Base() {} virtual void QueryInterface( const char* id, void** ppInterface ) = 0; virtual void Release() = 0; }; class ConnectionPoint : public Base { public: virtual void Bind( const char* id, void* pEvents ) = 0; virtual void Unbind( const char* id, void* pEvents ) = 0; }; class Factory : public Base { }; static const char* COMPONENT_ID = "Component"; class Component : public Base { public: virtual const char* GetString() const = 0; }; static const char* COMPONENT1_ID = "Component1"; class Component1 : public Base { public: virtual const char* GetString() const = 0; }; 

इस मामले में, हम घटक को जोड़ सकते हैं, जबकि पिछड़े संगतता को बनाए रखते हुए। हम इनहेरिटेंस द्वारा स्वयं इंटरफेस का विस्तार कर सकते हैं, या कारखानों के रूप में उनका उपयोग कर सकते हैं। हम इंटरफेस में ConnectionPoints लागू कर सकते हैं और असीमित रूप से इवेंट हैंडलर का उपयोग करने की संभावनाओं का विस्तार कर सकते हैं। उदाहरण में मेमोरी प्रबंधन बहुत सरल है, लेकिन आप COM के समान संदर्भ गिनती और स्मार्ट पॉइंटर्स का उपयोग कर सकते हैं।

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

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

अक्सर, एक अमूर्त कारखाना और एक फैक्ट्री फ़ंक्शन पर्याप्त होते हैं, जब यह स्पष्ट होता है कि भविष्य में घटक की क्षमताओं का विस्तार करने की आवश्यकता नहीं है।

जब कंपाइलर्स, थर्ड-पार्टी लाइब्रेरीज़ का स्पष्ट विनियमन होता है, साथ ही साथ यह समझना कि कार्य प्रणालियों के साथ पिछड़ी संगतता की आवश्यकता नहीं है, इंटरफ़ेस की सादगी के लिए PIMPL मुहावरा भी महान है।

निष्कर्ष में

ठीक से डिज़ाइन किया गया इंटरफ़ेस और कार्यान्वयन को छुपाने से समान घटकों का पुन: उपयोग करने पर कार्य में बहुत मदद मिलती है। इस मामले में, घटक को एक बार इकट्ठा और परीक्षण किया जाता है, जो परीक्षण और विकास के लिए संसाधनों को महत्वपूर्ण रूप से बचाता है। यह एक गतिशील रूप से भरी हुई लाइब्रेरी के रूप में उपलब्ध है और इसके कार्यान्वयन और संकलन की जटिलताओं को समझने के लिए डेवलपर की आवश्यकता के बिना, हमेशा उपयोग के लिए तैयार है। मैंने हेडर फ़ाइल के साथ लाइब्रेरी ली और उसका उपयोग किया, जीवन का आनंद लिया।

पुनश्च

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