एनीमेशन आर्किटेक्चर पैटर्न

Question

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

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

तो मेरे सवाल यह है: वस्तुओं के इन प्रकार के आयोजन इतना है कि यह कुशल है और आसान के लिए एक मानक प्रतिमान विस्तृत करने के है वहाँ (यानी यह नया एनिमेशन और नई वस्तुओं को जोड़ने के लिए आसान होना चाहिए)?

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

Answer 1

मैं इस तरह के "चरित्र" है, जो परिभाषित करता है क्या इन संस्थाओं के सब करने में सक्षम होना चाहिए के रूप में एक इंटरफेस होने की सलाह देते हैं। फिर आपके ड्रैगन और विज़ार्ड कक्षाएं केवल कार्यान्वयन हैं।

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

Answer 2

नहीं है, वहाँ बिल्कुल कोई मानक पैटर्न है।

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

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

class Dragon { 
enum State { asleep, flying, breathing_fire }; 
public: 
void draw() { /* old-school switch */ 
    switch (cur_state){ 
    case asleep: draw_asleep(); 
    case flying: draw_flying(); 
    case breathing_fire: draw_breathing_fire(); 
    } 
    } 
private: 
    void draw_asleep(); 
    void draw_flying(); 
    void draw_breathing_fire(); 
}; 

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

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

अंत में, अपने जादूगर और अपने ड्रैगन, आकर्षित करने के लिए एक सरल आवरण टेम्पलेट या functor पर्याप्त होगा:

struct Draw { 
    template <class S> 
    void operator()(S& s) { s.draw(); } 
}; 

बिंदु आप सिर्फ इसलिए कि वे दोनों का समर्थन दो अलग-अलग वर्गों के विलय करने की जरूरत नहीं है कि है एक ही तार्किक ऑपरेशन।