CRTP। स्थैतिक बहुरूपता। Mixin। विषय पर विचार

इस पोस्ट में, मैं C ++ में स्थैतिक बहुरूपता के विषय पर प्रतिबिंबित करता हूं, इसके आधार पर वास्तु समाधान। एक दिलचस्प मुहावरे पर विचार करें - CRTP । मैं इसके उपयोग के कुछ उदाहरण दूंगा। विशेष रूप से, मैं MixIn कक्षाओं की अवधारणा पर विचार करूंगा । मैं अपने स्वयं के ज्ञान को व्यवस्थित करने के लिए लिख रहा हूं, लेकिन शायद आप अपने लिए कुछ दिलचस्प पा सकते हैं।

परिचय

जैसा कि आप जानते हैं, C ++ एक बहु-प्रतिमान भाषा है। आप इस पर एक प्रक्रियात्मक शैली में लिख सकते हैं, भाषा निर्माण का उपयोग कर सकते हैं जो ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के लिए समर्थन प्रदान करते हैं, टेम्प्लेट प्रोग्रामिंग, एसटीएल और नई भाषा सुविधाओं ( लैम्ब्डा, एसटीडी :: फ़ंक्शन, एसटीडी :: बाइंड ) को सामान्य करने के लिए संभव बनाते हैं जो आपको एक कार्यात्मक शैली में लिखने की अनुमति देते हैं। रनटाइम में, और टेम्पलेट्स का मेटाप्रोग्रामिंग संकलन समय पर अपने शुद्ध रूप में कार्यात्मक प्रोग्रामिंग है।
इस तथ्य के बावजूद कि किसी भी वास्तविक बड़े कार्यक्रम में आप संभवतः इन सभी तकनीकों का मिश्रण पा सकते हैं, कक्षाओं की अवधारणा का उपयोग करके लागू एक वस्तु-उन्मुख प्रतिमान, एक खुला इंटरफ़ेस और बंद कार्यान्वयन (इनकैप्सुलेशन), विरासत, और आभासी कार्यों के माध्यम से लागू गतिशील बहुरूपता, निस्संदेह सबसे व्यापक रूप से इस्तेमाल किया जाता है।

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

स्थैतिक बहुरूपता

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

void process(base* b) { b->prepare(); b->work(); ... } 

हम निम्नलिखित कह सकते हैं: प्रक्रिया () फ़ंक्शन को दिए गए सूचक को उस ऑब्जेक्ट को इंगित करना चाहिए जो आधार इंटरफ़ेस (विरासत) को लागू करता है , और कार्यक्रम क्रियान्वयन के दौरान तैयारी () और कार्य () कार्यों के कार्यान्वयन का चयन होगा, जिसके आधार पर आधार प्रकार से प्राप्त संकेत बी ।

यदि हम निम्नलिखित कोड पर विचार करते हैं:

 template<typename T> void process(T t) { t.prepare(); t.work(); } 

तब हम यह कह सकते हैं कि, सबसे पहले, टाइप T के एक ऑब्जेक्ट को तैयार () और काम () फ़ंक्शन होना चाहिए, और दूसरी बात, इन कार्यों के कार्यान्वयन का संकलन वास्तविक समय टी के प्रकार के आधार पर, संकलन समय पर किया जाएगा ।
जैसा कि आप देख सकते हैं, दृष्टिकोण के सभी अंतरों के लिए, दोनों प्रकार के बहुरूपता के मुख्य (व्यावहारिक दृष्टिकोण से) सामान्य विशेषता यह है कि आपको विभिन्न प्रकार की वस्तुओं के साथ काम करते समय क्लाइंट कोड में कुछ भी बदलने की आवश्यकता नहीं है, बशर्ते कि ऊपर वर्णित आवश्यकताओं को पूरा करें।

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

उद्देश्यपूर्ण कारण, हालांकि, एक तरह से या इस तथ्य से दूसरे को कम किया जा सकता है कि, तात्कालिकता के बाद, टेम्पलेट कक्षाएं (फ़ंक्शन) के विभिन्न प्रकार होते हैं, अक्सर किसी भी तरह से एक दूसरे से जुड़े नहीं होते हैं।
यह बुरा क्यों है? अतिरिक्त चाल के बिना इन प्रकार की वस्तुएं ( बढ़ावा देखें :: संस्करण, बढ़ावा :: टपल, बढ़ावा :: किसी भी, बढ़ावा :: फ्यूजन आदि) को एक कंटेनर में नहीं डाला जा सकता है और इसलिए बैच संसाधित किया जाता है। उदाहरण के लिए, किसी वस्तु को बदलने के लिए निष्पादन के दौरान यह असंभव है - एक वर्ग का सदस्य, किसी अन्य प्रकार की वस्तु के साथ, "रणनीति" या "स्थिति" के कार्यान्वयन के ढांचे के भीतर। हालांकि ये पैटर्न अन्य तरीकों से भी बिना वर्ग पदानुक्रम के लागू किए जा सकते हैं, उदाहरण के लिए, std :: function या बस पॉइंटर्स टू फंक्शन, प्रतिबंध, हालांकि, चेहरे पर है।

लेकिन कोई भी हमें किसी एक प्रतिमान का सख्ती से पालन करने के लिए मजबूर नहीं करता है। OOP प्रतिमान और जेनेरिक प्रतिमान के जंक्शन पर इन दो दृष्टिकोणों के जंक्शन पर सबसे शक्तिशाली, लचीला और दिलचस्प समाधान उत्पन्न होता है। CRTP मुहावरा ऐसे प्रतिमानों के विलय का सिर्फ एक उदाहरण है।

CRTP

CRTP (घुंघराले आवर्ती टेम्पलेट पैटर्न) एक डिजाइन मुहावरा है कि एक वर्ग बेस क्लास से अपने आप को बेस क्लास के टेम्पलेट पैरामीटर के रूप में विरासत में मिला है। यह भ्रामक लगता है, लेकिन यह कोड में बहुत सरल लगता है।

 template <class T> class base{}; class derived : public base<derived> {}; 

यह हमें क्या दे सकता है? यह डिजाइन बेस क्लास से व्युत्पन्न वर्ग तक पहुंचना संभव बनाता है।

 template<typename D> struct base { void foo() {static_cast<D*>(this)->bar();} }; struct derived : base<derived> { void bar(); }; 

और इस तरह के संचार की संभावना, बदले में, कई दिलचस्प संभावनाएं खोलती है।

स्पष्ट इंटरफ़ेस

स्थैतिक बहुरूपता पर अध्याय में, मैंने स्पष्ट स्पष्टता की कमी को स्थैतिक बहुरूपता के व्यक्तिपरक दोष को बुलाया। इस विषय पर कोई भी तर्क दे सकता है, लेकिन एक रास्ता या दूसरा, स्पष्ट इंटरफ़ेस CRTP का उपयोग करके निर्धारित करना मुश्किल नहीं है। दरअसल, हम बेस क्लास से इन कार्यों के लिए कॉल के माध्यम से आवश्यक इंटरफ़ेस फ़ंक्शंस का एक सेट परिभाषित कर सकते हैं।

 template<typename D> struct base_worker { void work() {static_cast<D*>(this)->work_impl();} void prepare() {static_cast<D*>(this)->prepare_impl();} }; struct some_concrete_worker : base_worker<some_concrete_worker> { void work_impl(); //     void prepare_impl(); //    }; template<typename Worker> void polymorhic_work(const Worker& w) { w.prepare(); w.work(); }; int main() { some_concrete_worker w1; some_concrete_worker_2 w2; polymorhic_work(w1); //     polymorhic_work(w2); //  prepare_impl()  work_impl()  w1  w2 } 

इस तरह के डिजाइन की मदद से, एक डेवलपर (वास्तुकार) कुछ निश्चित वर्गों के इंटरफ़ेस को निर्दिष्ट कर सकता है, और बाकी के प्रोग्रामर को इस इंटरफ़ेस को लागू करते समय कुछ निर्देशित करना होगा। लेकिन CRTP क्षमताएं यही तक सीमित नहीं हैं ।

Mixin

MixIn एक डिजाइन तकनीक है जिसमें एक वर्ग (इंटरफ़ेस, मॉड्यूल, आदि) कुछ कार्यक्षमता को लागू करता है जिसे आप किसी अन्य वर्ग में "मिक्स" कर सकते हैं। अपने आप पर, MixIn वर्ग आमतौर पर उपयोग नहीं किया जाता है। यह तकनीक C ++ के लिए विशिष्ट नहीं है, और कुछ अन्य भाषाओं में भाषा निर्माण के स्तर पर इसका समर्थन किया जाता है।
C ++ में, MixIn के लिए कोई मूल समर्थन नहीं है, लेकिन फिर भी इस मुहावरे को CRTP का उपयोग करके पूरी तरह से लागू किया जा सकता है।
उदाहरण के लिए, MixIn वर्ग एक सिंगलटन या काउंटिंग ऑब्जेक्ट संदर्भों की कार्यक्षमता को लागू कर सकता है। और इस तरह के एक वर्ग का उपयोग करने के लिए, यह एक टेम्पलेट पैरामीटर के रूप में "अपने आप" से विरासत में पर्याप्त है।

 template<typename D> struct singleton{...}; class my_class : public singleton<my_class>{...}; 

यहाँ CRTP क्यों है? सिर्फ एक वर्ग से विरासत में क्यों नहीं जो हमें कुछ कार्यक्षमता की आवश्यकता होती है?

 struct singleton{...}; class my_class : singleton{...}; 

तथ्य यह है कि मिक्सइन के अंदर हमें विरासत में प्राप्त वर्ग (निर्माणकर्ता के लिए एक सिंगलटन के मामले में) के कार्यों तक पहुंच की आवश्यकता है और यहां सीआरटीपी बचाव के लिए आता है। और अगर एक सिंगलटन के साथ उदाहरण दूर की कौड़ी लगता है (वास्तव में, जो आज सिंगलटन का उपयोग करता है?), तो नीचे आपको वास्तविकता के करीब दो उदाहरण मिलेंगे।

Enable_shared_from_this

MixIn संरचना (बूस्ट) std :: enable_sared_from_this आपको एक नया स्वामित्व समूह बनाने के बिना किसी ऑब्जेक्ट पर साझा करने के लिए साझा करने की अनुमति देता है।

 struct bad { std::shared_ptr<bad> get() {return std::shared_ptr<bad>(this);} }; 

इस स्थिति में, प्रत्येक का उपयोग करते हुए प्राप्त किए गए प्रत्येक साझा_पार्ट : :: () फ़ंक्शन ऑब्जेक्ट के लिए एक नया स्वामित्व समूह खोलता है, और जब शेयर्ड_प्ट्र को नष्ट करने का समय होता है, तो हमारी वस्तु के लिए डिलीट एक से अधिक बार कॉल किया जाएगा।

इस तरह करना सही है:

 struct good : std::enable_shared_from_this<good> { std::shared_ptr<good> get() { return shared_from_this(); //    //  enable_shared_from_this } }; 

इस सहायक संरचना को इस तरह से व्यवस्थित किया गया है:

 template<typename T> struct enable_shared { weak_ptr<T> t_; enable_shared() { t_ = weak_ptr<T>(static_cast<T*>(this)); } shared_ptr<T> shared_from_this() { return shared_ptr<T>(t_); } }; 

जैसा कि आप देख सकते हैं, यहां CRTP बेस क्लास को व्युत्पन्न वर्ग के प्रकार को "देखने" और एक पॉइंटर को वापस करने की अनुमति देता है।

मिश्रण समारोह

MixIn कार्यक्षमता को कुछ वर्ग के अंदर शामिल करने की आवश्यकता नहीं है। कभी-कभी इसे एक मुफ्त फ़ंक्शन के रूप में लागू करना संभव है। एक उदाहरण के रूप में, हम सभी वर्गों के लिए "! =" ऑपरेटर को कार्यान्वित करते हैं जिसके लिए "==" ऑपरेटर परिभाषित किया गया है।

 template<typename D> struct non_equalable{}; template<typename D> bool operator != (const non_equalable<D>& lhs, const non_equalable<D>& rhs) { return !(static_cast<const D&>(lhs) == static_cast<const D&>(rhs)); } 

जैसा कि आप देख सकते हैं, ऑपरेटर के अंदर! = हम इस तथ्य का उपयोग करते हैं कि non_equalable व्युत्पन्न प्रकार में परिभाषित "==" ऑपरेटर का उपयोग कर सकता है।
आप इस MixIn का उपयोग इस प्रकार कर सकते हैं:

 struct some_struct : non_equalable<some_struct> { some_struct(int w) : i_(w){} int i_; }; bool operator == (const some_struct& lhs, const some_struct& rhs) { return lhs.i_ == rhs.i_; } int main() { some_struct s1(3); some_struct s2(4); std::cout << (s1 != s2) << std::endl; } 

मिक्स अन्य तरीके के आसपास

कल्पना कीजिए कि हम खेल अंतरिक्ष यान की कक्षाओं के कार्यान्वयन को लिख रहे हैं। हमारे जहाज एक ही एल्गोरिदम का पालन करेंगे, कुछ बिंदुओं के अपवाद के साथ, उदाहरण के लिए, शेष ईंधन की गणना के लिए तंत्र और वर्तमान गति जहाज से जहाज तक भिन्न होगी। पैटर्न टेम्पलेट पद्धति का क्लासिक कार्यान्वयन (और यह है) इस तरह दिखेगा:

 class space_ship { public: // ... void move() { if(!fuel()) return; int current_speed = speed(); // further actions ... } virtual ~space_ship(){} private: virtual bool fuel() const = 0; virtual int speed() const = 0; }; class interceptor : public space_ship { public: // ... private: bool fuel() const { ... } int speed() const { ... } }; class other_ship : public space_ship { ... }; class other_ship_2 : public space_ship { ... }; // … 

अब CRTP को लागू करने का प्रयास करें।

 template<typename D> class space_ship { public: void move() { if(!static_cast<D*>(this)->fuel()) return; int current_speed = static_cast<D*>(this)->speed(); // ... } }; class interceptor : public space_ship<interceptor> { public: bool fuel() const; int speed() const; }; 

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

इस दृष्टिकोण के साथ मिक्सइन की अवधारणा को उल्टा कर दिया गया है। मुख्य कार्य बेस क्लास में किया जाता है, और हम व्युत्पन्न वर्गों से अतिरिक्त (अलग) कार्यक्षमता को "मिक्स" करते हैं।

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

मिक्सिन भिन्नता

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

 struct access { template<typename Impl> static void on_handle_connect(Impl* impl) {impl->handle_connect();} template<typename Impl> static void on_handle_response(Impl* impl) {impl->handle_response();} }; 

अब आधार वर्गों से, हम व्युत्पन्न के कार्यों को नहीं, बल्कि मध्यवर्ती संरचना के कार्यों को कहते हैं।

 template<typename D> struct connection_handler { // ... void on_connection() { access::on_handle_connect(static_cast<D*>(this)); } }; template<typename D> struct response_handler { // ... void on_response() { access::on_handle_response(static_cast<D*>(this)); } }; 

व्युत्पन्न वर्ग में, दोस्तों के लिए केवल एक्सेस स्ट्रक्चर बनाने के लिए यह हमारे लिए पर्याप्त है।

 class combined_handler : public connection_handler<worker>, public response_handler<worker> { private: friend struct access; void handle_connect(){ std::cout << __PRETTY_FUNCTION__ << std::endl; } void handle_response(){ std::cout << __PRETTY_FUNCTION__ << std::endl; } }; 

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