आगंतुक पैटर्न। उन्नत उपयोग

नमस्ते, प्रिय हभ्रवचन!

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

प्रागितिहास

कल्पना कीजिए कि हम एक 2D गेम डिजाइन कर रहे हैं जिसमें फल एक पेड़ से गिरते हैं, जिस तरह से शाखाओं को मारते हैं। खेल का लक्ष्य टोकरी को पेड़ के नीचे ले जाकर सभी फलों को पकड़ना है।
हम निम्न वर्ग आरेख बनाते हैं:


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

उदाहरण के लिए, यह एक सेब खींचने के लिए कोड है:

void Apple::draw() { Graphics& graphics = GetGraphicsFromSomeMagicalPlace(); Texture& texture = GetAppleTextureFromEvenMoreMagicalPlace(); graphics.draw(texture, x(), y(), angle()); } 

हमारी मुख्य ड्राइंग विधि, जिसे गेम लूप में कहा जाता है, कुछ इस तरह दिखाई देती है:

 void Game::draw(std::vector<Object*>& allObjects) { std::vector<Object*>::iterator it = allObjects.begin(); std::vector<Object*>::iterator end = allObjects.end(); while(it != end) { (*it)->draw(); ++it; } } 

Wuhu! बहुरूपता शांत है, हम सोचते हैं और खेल लिखना जारी रखते हैं। हम वास्तविक रूप से गिरावट का चित्रण करना चाहते हैं, इसलिए हम Box2D लाइब्रेरी का उपयोग करने का निर्णय लेते हैं। आरेख में कुछ वर्गों को Box2D से एक ऑब्जेक्ट के लिए एक पॉइंटर रखने की आवश्यकता होती है, लेकिन सभी नहीं। उदाहरण के लिए, ट्री क्लास को इस तरह की कार्यक्षमता की आवश्यकता नहीं है, इसका कार्य केवल स्वयं को आकर्षित करना और फलों की संख्या के बारे में जानकारी संग्रहीत करना है। इसलिए, हम इस पॉइंटर को बेस क्लास ऑब्जेक्ट में नहीं डालेंगे, लेकिन एक इंटरमीडिएट क्लास Box2DObject बनाएँ, जिसके बाद हमारा आरेख कुछ इस तरह दिखाई देगा (केवल आरेख का ऊपरी भाग दिखाया गया है):

B2Body ऑब्जेक्ट बनाने के लिए जिम्मेदार कोड प्रत्येक व्युत्पन्न वर्ग के कंस्ट्रक्टर में होगा, और डिलीट करने के लिए जिम्मेदार कोड डिस्ट्रक्टर में होगा। उदाहरण के लिए ब्रांच क्लास लें:

 Branch::Branch() { b2BodyDef bodyDef; bodyDef.type = b2_staticBody; b2Body* body = GetBox2DWorldFromSomewhrere().CreateBody(&bodyDef); b2PolygonShape shape; shape.SetAsBox(BRANCH_WIDTH, BRANCH_HEIGHT); b2FixtureDef fixtureDef; fixtureDef.shape = &shape; fixtureDef.friction = BRANCH_FRICTION; fixtureDef.restitution = BRANCH_RESTITUTION; body->CreateFixture(&fixtureDef); m_box2dBody = body; body->SetUserData(this); } Branch::~Branch() { GetBox2DWorldFromSomewhrere().DestroyBody(m_box2dBody); } 

फिर से कूल, हम सोचते हैं। यद्यपि "आभासीता" की अवधारणा डिजाइनरों के लिए लागू नहीं है, फिर भी कोई ड्राइंग के साथ एक सादृश्य बना सकता है - प्रत्येक वर्ग अपने तरीके से Box2D से ऑब्जेक्ट बनाता है।
हम ध्यान देते हैं कि हटाए गए कोड सभी Box2DObject-व्युत्पन्न वर्गों के लिए समान होंगे, इसलिए इसे Box2DObject विध्वंसक के लिए स्थानांतरित करना तर्कसंगत है। इस तरह:

 Box2DObject::~Box2DObject() { GetBox2DWorldFromSomewhrere().DestroyBody(m_box2dBody); } 

इसके अलावा, एक नारंगी और एक सेब बनाने के लिए कोड अलग नहीं है, इसलिए हम इसे फ्रूट बेस क्लास के कंस्ट्रक्टर में स्थानांतरित करते हैं:

 Fruit::Fruit() { b2BodyDef bodyDef; bodyDef.type = b2_dynamicBody; b2CircleShape shape; shape.m_radius = FRUIT_RADIUS; b2Body* body = GetBox2DWorldFromSomewhrere().CreateBody(&bodyDef); b2FixtureDef fixtureDef; fixtureDef.shape = &shape; fixtureDef.density = FRUIT_DENSITY; fixtureDef.friction = FRUIT_FRICTION; fixtureDef.restitution = FRUIT_RESTITUTION; body->CreateFixture(&fixtureDef); m_box2DBody = body; body->SetUserData(this); } 

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

आगंतुक पैटर्न

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

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

 class Object { public: virtual void accept(Visitor& visitor) = 0; //…Everything else }; 

इसके बाद पदानुक्रम इस तरह हो जाएगा:

स्वीकार पद्धति का कार्यान्वयन सभी पत्तियों में समान है और इसमें एक पंक्ति होती है।

 class Tree : public Object { public: virtual void accept(Visitor& visitor) { visitor.visit(*this); // Superhard to understand single line of code } //…Everything else }; 

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

 void Painter::visit(Apple& apple) { m_graphics.draw(m_appleTexture, apple.x(), apple.y(), apple.angle()); } void Painter::visit(Tree& tree) { m_graphics.draw(m_treeTexture, tree.x(), tree.y()); } 

पैरामीटर के प्रकार के आधार पर, हम एक सेब या एक पेड़ खींचते हैं। निर्माता वर्ग में समान सिद्धांत:

 void Creator::visit(Basket& basket) { // Setup basket b2Body } void Creator::visit(Branch& branch) { // Setup branch b2Body } 

हमारी सामान्य ड्राइंग विधि, जिसे गेम लूप से कहा जाता है, बन जाएगी:

 void Game::draw(std::vector<Object*>& allObjects) { Painter& painter = GetPainter(); std::vector<Object*>::iterator it = allObjects.begin(); std::vector<Object*>::iterator end = allObjects.end(); while(it != end) { (*it)->accept(painter); ++it; } } 

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

UpcastVisitor इंटरलेयर

यहां हम काम पूरा कर सकते हैं और आनंद ले सकते हैं, लेकिन हम यह देख कर भयभीत हैं कि कोड को कई स्थानों पर दोहराया गया है। विध्वंसक वर्ग में, सभी विधियों में समान रूप है, उदाहरण के लिए, समान कोड का उपयोग सेब और नारंगी के लिए किया जाता है:

 void Destroyer::visit(Apple& apple) { m_box2dWorld.DestroyBody(apple.b2Body()); } void Destroyer::visit(Orange& orange) { m_box2dWorld.DestroyBody(orange.b2Body()); } 

Box2DObject से विरासत में मिली सभी कक्षाओं को देखने के बाद इसे विध्वंसक में लागू किया गया। आपको अतिरिक्त visitBox2DObject पद्धति में डुप्लिकेट कोड बनाना होगा और इसे हर जगह से कॉल करना होगा:

 void Destroyer::visitBox2DObject(Box2DObject& object) { m_box2dWorld.DestroyBody(object.b2Body()); } void Destroyer::visit(Apple& apple) { visitBox2DObject(apple); } void Destroyer::visit(Orange& orange) { visitBox2DObject(orange); } 

और इसलिए मैं ऐसा नहीं करना चाहता। मैं चाहता हूं कि डिस्ट्रॉयर वर्ग में ओवरलोड विधियों के एक समूह के बजाय जिसमें समान कोड हो, "सही" प्रकार के पैरामीटर के साथ एक ही होना चाहिए - Box2DObject। और इसलिए कि यह ऐप्पल, ऑरेंज, बास्केट, आदि के लिए काम करता है, उदाहरण के लिए:

 class Destroyer : public Visitor { public: void visit(Box2DObject& object) { m_box2dWorld.DestroyBody(object.b2Body()); } // ... }; 

एक मौका लें और इस विधि को आधार वर्ग में जोड़ें:

 class Visitor { public: void visit(Box2DObject& object); // … }; 

दुर्भाग्य से, यह कभी नहीं कहा जाएगा, क्योंकि Box2DObject वर्ग में स्वीकार पद्धति का कोई कार्यान्वयन नहीं है। और यहां तक ​​कि अगर यह था, तो इसे व्युत्पन्न वर्गों में अतिभारित किया जाएगा और परिणाम एक ही होगा - Box2DObject पैरामीटर प्रकार के साथ यात्रा विधि कभी नहीं कहा जाएगा। फिर मैं बेस विजिटर क्लास और क्रिएटर और डिस्ट्रॉयर वर्गों के बीच एक विज़िटर लेयर के विचार के साथ आया। मैंने इस लेयर को UpcastVisitor कहा है। इस तरह से हमारे आगंतुकों का पदानुक्रम बदल जाएगा:

अब सबसे महत्वपूर्ण बात कोड है:

 void UpcastVisitor::visit(Object& object) { } void UpcastVisitor::visit(Box2DObject& object) { visit(static_cast<Object&>(object)); } void UpcastVisitor::visit(Fruit& fruit) { visit(static_cast<Box2DObject&>(fruit)); } void UpcastVisitor::visit(Apple& apple) { visit(static_cast<Fruit&>(apple)); } void UpcastVisitor::visit(Orange& orange) { visit(static_cast<Fruit&>(orange)); } 

यदि Apple के प्रकार का एक ऑब्जेक्ट UpcastVisitor को मिलता है, तो वह इसे टाइप फल में परिवर्तित करता है, फिर Box2DObject टाइप करने के लिए और ऑब्जेक्ट को टाइप करने के लिए बहुत अंत में। इसी सिद्धांत के अनुसार, UpcastVisitor'e में प्रत्येक का दौरा किया वर्ग सबसे बुनियादी एक को पदानुक्रम श्रृंखला के साथ जाता है। अब हमें UpcastVisitor से विनाशक वर्ग विरासत में मिला और आनन्दित हुए! यदि UpcastVisitor को सही तरीके से लागू किया गया है, तो हमें केवल एक विधि को ओवरलोड करना होगा।

 class Destroyer : public UpcastVisitor { public: virtual void visit(Box2DObject& object) { m_box2dWorld.DestroyBody(object.b2Body()); } // ... }; 

UpcastVisitor आपके लिए क्रिएटर क्लास में भी उपयोगी है, क्योंकि Box2D एंटिटी क्रिएशन कोड ऐप्पल और ऑरेंज के लिए समान है:

 class Creator : public UpcastVisitor { public: virtual void visit(Fruit& fruit) { // Setup fruit's Box2D body } // … }; 

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

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

आपका ध्यान के लिए धन्यवाद! मुझे उम्मीद है कि यह लेख किसी के लिए उपयोगी होगा!

अपडेट :
7vies आपको बताता है कि UpcastVisitor में आप static_cast से निम्न प्रकार से छुटकारा पा सकते हैं:

 void UpcastVisitor::visit(Box2DObject& object) { Object& o = object; visit(o); } 

अच्छी सलाह के लिए धन्यवाद!