प्रेरणा के स्रोत

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

Aras स्लाइड यहाँ उपलब्ध हैं: http://aras-p.info/texts/files/2018Academy - ECS-DoD.pdf , और कोड github पर है: https://github.com/aras-p/dod-playground ।

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

Spoiler: सभी OOD उल्लंघनों को खत्म करने से ECS रूपांतरणों के समान Aras के समान प्रदर्शन में सुधार होता है, यह RAM का कम उपयोग करता है और ECS संस्करण की तुलना में कोड की कम लाइनों की आवश्यकता होती है!

TL; DR: यह निष्कर्ष निकालने से पहले कि OOP बेकार है और ECS ड्राइव करता है, OOD (सही तरीके से OOP का उपयोग कैसे करें, यह जानने के लिए) को रोकें और जांचें, और रिलेशनल मॉडल (ECS को सही तरीके से लागू करने के लिए कैसे पता करें) को भी समझें।

मैं लंबे समय से मंच पर ईसीएस के बारे में बहुत सारी चर्चाओं में भाग ले रहा हूं, आंशिक रूप से क्योंकि मुझे नहीं लगता कि यह मॉडल एक अलग शब्द के रूप में मौजूद है ( स्पॉइलर: यह रिलेशनल मॉडल का सिर्फ एक एड-हॉक संस्करण है , बल्कि इसलिए भी क्योंकि ईसीएस पैटर्न को बढ़ावा देने वाली लगभग हर पोस्ट, प्रेजेंटेशन या आर्टिकल निम्न संरचना का अनुसरण करता है:

भयानक OOP कोड का एक उदाहरण दिखाएं, जिसके कार्यान्वयन में वंशानुक्रम के अत्यधिक उपयोग के कारण भयानक दोष हैं (जिसका अर्थ है कि यह कार्यान्वयन OOD के कई सिद्धांतों का उल्लंघन करता है)।
यह दिखाने के लिए कि रचना वंशानुक्रम की तुलना में एक बेहतर समाधान है (और यह उल्लेख नहीं है कि OOD वास्तव में हमें वही सबक देता है)।
दिखाएँ कि रिलेशनल मॉडल गेम के लिए बढ़िया है (लेकिन इसे "ईसीएस" कहें)।

इस तरह की संरचना मुझे प्रभावित करती है क्योंकि: (ए) यह एक चाल है "भरवां" ... यह नरम से गर्म (बुरा कोड और अच्छा कोड) की तुलना करता है ... और यह अनुचित है, भले ही अनजाने में किया गया हो और यह प्रदर्शित करने की आवश्यकता नहीं है कि नई वास्तुकला अच्छी है; और, अधिक महत्वपूर्ण बात: (बी) इसका एक साइड इफेक्ट है - ऐसा दृष्टिकोण ज्ञान को दबा देता है और अनजाने में आधी सदी के लिए किए गए अध्ययन के साथ पाठकों को परिचित से अलग कर देता है। उन्होंने 1960 के दशक में रिलेशनल मॉडल के बारे में लिखना शुरू किया। 70 और 80 के दशक के दौरान, इस मॉडल में काफी सुधार हुआ है। शुरुआती में अक्सर सवाल होता है कि " आप इस डेटा को किस वर्ग में रखना चाहते हैं? ", और जवाब में उन्हें अक्सर कुछ अस्पष्ट कहा जाता है, जैसे " आपको केवल अनुभव प्राप्त करने की आवश्यकता है और फिर आप सिर्फ आंतरिक रूप से समझना सीखते हैं " ... लेकिन 70 के दशक में यह प्रश्न सक्रिय रूप से था। अध्ययन किया और सामान्य मामले में एक औपचारिक जवाब काटा गया; इसे डेटाबेस सामान्यीकरण कहा जाता है । मौजूदा शोध और ईसीएस को पूरी तरह से नया और आधुनिक समाधान बताते हुए, आप इस ज्ञान को शुरुआती लोगों से छिपाते हैं।

ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग की मूल बातें बहुत पहले ही रखी गई थीं, यदि पहले नहीं ( 1950 के दशक के काम में इस शैली की खोज की जाने लगी )! हालांकि, यह 1990 के दशक में था कि ऑब्जेक्ट-ओरिएंटेशन फैशनेबल, वायरल हो गया, और बहुत जल्दी प्रमुख प्रोग्रामिंग प्रतिमान में बदल गया। जावा और ( मानकीकृत संस्करण ) C ++ सहित कई नई OO भाषाओं की लोकप्रियता का विस्फोट हुआ है। हालाँकि, चूंकि यह प्रचार के कारण था, सभी को अपने रिज्यूम में लिखने के लिए इस हाई-प्रोफाइल कॉन्सेप्ट को जानना आवश्यक था , लेकिन कुछ ही वास्तव में इसमें शामिल हुए। इन नई भाषाओं ने OO की कई विशेषताओं में से कीवर्ड - क्लास , वर्चुअल , एक्सटेंड , इम्प्लीमेंट - बनाए, और मेरा मानना है कि इसीलिए उस समय OO को दो अलग-अलग संस्थाओं में विभाजित किया गया, जो अपना जीवन जीते हैं।

मैं इन OO- प्रेरित भाषा सुविधाओं के उपयोग को " OOP " और OO- प्रेरित डिजाइन / वास्तुकला तकनीकों के उपयोग " OOD " के रूप में संदर्भित करूंगा। सभी ने बहुत जल्दी OOP उठाया। शैक्षिक संस्थानों में ओओ पाठ्यक्रम हैं जो नए ओओपी प्रोग्रामर को बेक करते हैं ... हालांकि, ओओडी का ज्ञान पीछे रहता है।

मेरा मानना है कि वह कोड जो OOP की भाषा सुविधाओं का उपयोग करता है, लेकिन OOD डिजाइन के सिद्धांतों का पालन नहीं करता है, एक OO कोड नहीं है । OOP के खिलाफ अधिकांश आलोचनाएं उदाहरण के लिए आंत कोड का उपयोग करती हैं, जो वास्तव में एक OO कोड नहीं है।

OOP कोड की बहुत खराब प्रतिष्ठा है, और विशेष रूप से क्योंकि OOP कोड में से अधिकांश OOD के सिद्धांतों का पालन नहीं करते हैं, और इसलिए "OO" कोड नहीं है।

आवश्यक शर्तें

जैसा कि ऊपर कहा गया है, 1990 का दशक "ओओ फैशन" का चरम बन गया, और यह उस समय था कि "खराब ओओपी" शायद सबसे खराब था। यदि आपने उस समय ओओपी का अध्ययन किया था, तो आपको "ओओपी के चार स्तंभ" के बारे में पता चला था:

सार संक्षेप
कैप्सूलीकरण
बहुरूपता
विरासत

मैं उन्हें चार स्तंभ नहीं, बल्कि "चार ओओपी उपकरण" कहना पसंद करता हूं। ये ऐसे उपकरण हैं जिनका उपयोग आप समस्याओं को हल करने के लिए कर सकते हैं। हालाँकि, यह पता लगाना पर्याप्त नहीं है कि उपकरण कैसे काम करता है, आपको यह जानने की आवश्यकता है कि इसका उपयोग कब करना है ... शिक्षकों की ओर से, लोगों को एक नया उपकरण सिखाना गैर-जिम्मेदाराना है, यह बताना नहीं कि उनमें से प्रत्येक कब उपयोग करने लायक है। 2000 के दशक की शुरुआत में, इन उपकरणों के सक्रिय दुरुपयोग का विरोध किया गया था, जो OOD सोच की "दूसरी लहर" थी। इसका परिणाम SOLID mnemonics का उद्भव था, जिसने वास्तुकला की ताकत का मूल्यांकन करने का एक त्वरित तरीका प्रदान किया। यह ध्यान दिया जाना चाहिए कि यह ज्ञान वास्तव में 90 के दशक में व्यापक था, लेकिन अभी तक एक शांत परिचित प्राप्त नहीं हुआ है, जिसने उन्हें पांच बुनियादी सिद्धांतों के रूप में तय किया गया था ...

एकमात्र जिम्मेदारी का सिद्धांत ( S ingle जिम्मेदारी सिद्धांत)। प्रत्येक वर्ग के परिवर्तन का केवल एक कारण होना चाहिए। यदि कक्षा "ए" में दो जिम्मेदारियां हैं, तो आपको उनमें से प्रत्येक को व्यक्तिगत रूप से संसाधित करने के लिए वर्ग "बी" और "सी" बनाने की आवश्यकता है, और फिर "बी" और "सी" से "ए" बनाएं।
खुलेपन / बंद करने का सिद्धांत ( ओ पेन / बंद सिद्धांत)। समय के साथ सॉफ्टवेयर बदलता है ( यानी इसका समर्थन महत्वपूर्ण है )। उन हिस्सों को लगाने की कोशिश करें जो कार्यान्वयन में बदलने की संभावना रखते हैं ( यानी, विशिष्ट कक्षाओं में ) और उन हिस्सों के आधार पर इंटरफेस बनाते हैं जो बदलने की संभावना नहीं है ( उदाहरण के लिए, सार आधार वर्ग )।
बारबरा लिस्कोव ( एल iskov प्रतिस्थापन सिद्धांत) का प्रतिस्थापन सिद्धांत। एक इंटरफ़ेस के प्रत्येक कार्यान्वयन को इस इंटरफ़ेस की आवश्यकताओं को पूरा करना होगा, अर्थात इंटरफ़ेस के साथ काम करने वाले किसी भी एल्गोरिदम को किसी भी कार्यान्वयन के साथ काम करना चाहिए।
इंटरफ़ेस के अलगाव का सिद्धांत ( I nterface अलगाव समूह)। इंटरफेस को जितना संभव हो उतना छोटा बनाएं ताकि कोड आधार की सबसे छोटी राशि के बारे में कोड का प्रत्येक भाग "जानता" हो, उदाहरण के लिए, अनावश्यक निर्भरता से बचा जाता है। यह टिप C ++ के लिए भी अच्छा है, जहां संकलन समय बहुत बड़ा हो जाता है यदि आप इसका पालन नहीं करते हैं।
निर्भरता उलटा का सिद्धांत ( डी एपेंडेंसी उलटा सिद्धांत)। दो विशिष्ट कार्यान्वयनों के बजाय जो सीधे संवाद करते हैं (और एक दूसरे पर निर्भर करते हैं), उन्हें आमतौर पर उनके संचार इंटरफेस को तीसरे वर्ग के रूप में औपचारिक रूप से अलग किया जा सकता है, जिसका उपयोग उनके बीच के इंटरफेस के रूप में किया जाता है। यह एक अमूर्त आधार वर्ग हो सकता है जो उनके बीच इस्तेमाल किए गए तरीकों की कॉल को परिभाषित करता है, या यहां तक कि सिर्फ एक पीओडी संरचना है जो उनके बीच स्थानांतरित डेटा को परिभाषित करता है।
संक्षिप्त एसओएलआईडी में एक और सिद्धांत शामिल नहीं है, लेकिन मुझे यकीन है कि यह बहुत महत्वपूर्ण है: "उत्तराधिकार पर रचना को प्राथमिकता दें" (समग्र पुन: उपयोग सिद्धांत)। रचना डिफ़ॉल्ट रूप से सही विकल्प है । इनहेरिटेंस को उन मामलों के लिए छोड़ दिया जाना चाहिए जब यह बिल्कुल आवश्यक हो।

तो हमें SOLID-C (++) मिलता है

नीचे मैं इन सिद्धांतों का संदर्भ दूंगा, उन्हें एसआरपी - एसआरपी, ओसीपी, एलएसपी, आईएसपी, डीआईपी, सीआरपी ...

कुछ और नोट:

OOD में, इंटरफेस और कार्यान्वयन की अवधारणाओं को किसी विशिष्ट OOP कीवर्ड से नहीं जोड़ा जा सकता है। C ++ में, हम अक्सर एब्सट्रैक्ट बेस क्लास और वर्चुअल फ़ंक्शंस के साथ इंटरफेस बनाते हैं, और फिर इन बेस क्लास से इनहेरिट करते हैं ... लेकिन यह इंटरफ़ेस के सिद्धांत को लागू करने का केवल एक विशिष्ट तरीका है। C ++ में, हम PIMPL , अपारदर्शी पॉइंटर्स , बतख टाइपिंग , टाइपीडिफ आदि का भी उपयोग कर सकते हैं ... आप एक OOD संरचना बना सकते हैं और फिर इसे C में कार्यान्वित कर सकते हैं, जिसमें कोई OOP भाषा कीवर्ड नहीं हैं! इसलिए जब मैं इंटरफेस के बारे में बात करता हूं, तो मुझे जरूरी नहीं कि आभासी कार्यों का मतलब है - मैं कार्यान्वयन को छिपाने के सिद्धांत के बारे में बात कर रहा हूं। इंटरफेस बहुरूपी हो सकते हैं, लेकिन अधिक बार वे नहीं हैं! बहुरूपता बहुत कम ही सही ढंग से उपयोग किया जाता है, लेकिन सभी सॉफ्टवेयर के लिए इंटरफेस एक बुनियादी अवधारणा है।
- जैसा कि मैंने ऊपर स्पष्ट किया है, यदि आप एक POD संरचना बनाते हैं जो केवल एक वर्ग से दूसरे वर्ग में संचरण के लिए कुछ डेटा संग्रहीत करता है, तो इस संरचना का उपयोग इंटरफ़ेस के रूप में किया जाता है - यह डेटा का एक औपचारिक विवरण है ।
- यहां तक कि अगर आप केवल सार्वजनिक और निजी भागों के साथ एक अलग वर्ग बनाते हैं, तो जो कुछ सामान्य भाग में है वह एक इंटरफ़ेस है , और निजी हिस्से में सब कुछ एक कार्यान्वयन है ।
वंशानुक्रम में वास्तव में (कम से कम) दो प्रकार होते हैं - इंटरफ़ेस वंशानुक्रम और कार्यान्वयन विरासत।
- C ++ में, इंटरफ़ेस इनहेरिटेंस में शुद्ध वर्चुअल फ़ंक्शंस, PIMPL, सशर्त टाइपडेफ़ के साथ अमूर्त आधार कक्षाएं शामिल हैं। जावा में, इंटरफ़ेस विरासत को इम्प्लीमेंट कीवर्ड के माध्यम से व्यक्त किया जाता है।
- C ++ में, कार्यान्वयन की विरासत हर बार होती है जब आधार वर्ग में शुद्ध आभासी कार्यों के अलावा कुछ और होता है। जावा में, कार्यान्वयन वंशानुक्रम को विस्तारित कीवर्ड का उपयोग करके व्यक्त किया गया है ।
- OOD के पास इंटरफेस विरासत में लेने के बहुत सारे नियम हैं, लेकिन कार्यान्वयन की विरासत आमतौर पर "काटने के साथ कोड" के रूप में विचार करने योग्य है!

और अंत में, मुझे भयानक ओओपी प्रशिक्षण के कुछ उदाहरण दिखाने चाहिए और यह वास्तविक जीवन में बुरे कोड की ओर जाता है (और ओओपी की खराब प्रतिष्ठा)।

जब आपको पदानुक्रम / वंशानुक्रम पढ़ाया जाता है, तो आपको एक समान कार्य दिया जा सकता है: मान लीजिए कि आपके पास एक विश्वविद्यालय आवेदन है जिसमें छात्रों और कर्मचारियों की निर्देशिका है। आप बेस क्लास पर्सन, और फिर स्टूडेंट क्लास और स्टाफ क्लास बना सकते हैं, जो पर्सन से विरासत में मिला है।

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

यह वास्तव में कार्यान्वयनों की विरासत और इंटरफेस की विरासत के बीच अंतर को प्रदर्शित करने के लिए एक अच्छा उदाहरण है।
- यदि आप कार्यान्वयन विरासत दृष्टिकोण का उपयोग करते हैं, तो आप एलएसपी की पूरी तरह से उपेक्षा करते हैं और व्यावहारिक दृष्टिकोण से, कोड को पुन: उपयोग करने की संभावना के बारे में सोचते हैं, विरासत को एक उपकरण के रूप में उपयोग करते हैं।
  
  इस दृष्टिकोण से, निम्नलिखित पूरी तरह से तार्किक है:
```
struct Square { int width; }; struct Rectangle : Square { int height; }; 
```
  चौकोर में केवल चौड़ाई होती है, और आयत की चौड़ाई + ऊँचाई होती है, यानी ऊँचाई के घटक के साथ वर्ग का विस्तार करने पर, हमें एक आयत मिलती है!
  - जैसा कि आपने अनुमान लगाया होगा, OOD का कहना है कि ऐसा करना ( शायद ) गलत है। मैंने कहा "शायद" क्योंकि यहाँ आप इंटरफ़ेस की निहित विशेषताओं के बारे में तर्क दे सकते हैं ... ओह अच्छी तरह से।
    
    एक वर्ग में हमेशा समान ऊंचाई और चौड़ाई होती है, इसलिए वर्ग के इंटरफ़ेस से यह मान लेना पूरी तरह से सही है कि क्षेत्र "चौड़ाई * चौड़ाई" है।
    
    एक वर्ग से, आयतों के वर्ग (एलएसपी के अनुसार) को वर्ग इंटरफ़ेस के नियमों का पालन करना चाहिए । कोई भी एल्गोरिथ्म जो एक वर्ग के लिए सही ढंग से काम करता है, एक आयत के लिए भी सही ढंग से काम करना चाहिए।
  - दूसरा एल्गोरिथ्म लें:
```
 std::vector<Square*> shapes; int area = 0; for(auto s : shapes) area += s->width * s->width; 
```
    यह वर्गों (अपने क्षेत्रों की राशि की गणना) के लिए सही ढंग से काम करेगा, लेकिन आयतों के लिए काम नहीं करेगा।
    
    इसलिए, आयत एलएसपी सिद्धांत का उल्लंघन करता है।
- यदि आप इंटरफ़ेस वंशानुक्रम दृष्टिकोण का उपयोग करते हैं, तो न तो स्क्वायर और न ही आयत एक दूसरे से विरासत में मिलेंगे। वर्ग और आयत के लिए इंटरफेस वास्तव में अलग हैं, और एक दूसरे का सुपरसेट नहीं है।
- इसलिए, OOD कार्यान्वयन विरासत के उपयोग को हतोत्साहित करता है। जैसा कि ऊपर कहा गया है, यदि आप कोड का पुन: उपयोग करना चाहते हैं, तो OOD कहता है कि रचना सही विकल्प है!
  - तो C ++ कार्यान्वयन की विरासत पदानुक्रम के लिए उपरोक्त (खराब) कोड का सही संस्करण इस तरह दिखता है:
```
 struct Shape { virtual int area() const = 0; }; struct Square : public virtual Shape { virtual int area() const { return width * width; }; int width; }; struct Rectangle : private Square, public virtual Shape { virtual int area() const { return width * height; }; int height; }; 
```
    - जावा में "पब्लिक वर्चुअल" का अर्थ है "लागू करना"। इंटरफ़ेस को लागू करते समय उपयोग किया जाता है।
    - "निजी" आपको इसके इंटरफ़ेस को विरासत में दिए बिना आधार वर्ग का विस्तार करने की अनुमति देता है - इस मामले में, आयत एक वर्ग नहीं है , हालांकि यह उससे विरासत में मिला है।
  - मैं इस तरह के कोड को लिखने की अनुशंसा नहीं करता, लेकिन यदि आप कार्यान्वयन की विरासत का उपयोग करना चाहते हैं, तो आपको बस ऐसा करने की आवश्यकता है!

टीएल; डीआर - आपके ओओपी वर्ग ने आपको बताया कि विरासत क्या थी। आपके लापता OOD वर्ग ने आपको बताया होगा कि वह 99% समय का उपयोग नहीं करेगा!

इकाई / घटक अवधारणाओं

किसी और चीज से निपटने के बाद, अरस जहां शुरू हुआ - एक "विशिष्ट ईओपी" के तथाकथित शुरुआती बिंदु पर आगे बढ़ें।

लेकिन शुरुआत के लिए, एक और इसके अलावा - अरास इस कोड को "पारंपरिक ओओपी" कहता है, और मैं इस पर आपत्ति करना चाहता हूं। यह कोड वास्तविक दुनिया में OOP के लिए विशिष्ट हो सकता है, लेकिन, ऊपर के उदाहरणों की तरह, यह OO के सभी प्रकार के बुनियादी सिद्धांतों का उल्लंघन करता है, इसलिए इसे बिल्कुल भी पारंपरिक नहीं माना जाना चाहिए।

मैं ECS की ओर संरचना का पुन : निर्माण शुरू करने से पहले पहली बार के साथ शुरू करूंगा: "इसे फिर से विंडोज पर काम करें" 3529f232510c95f53112bbfff87df6bbc6aa1fae

 // ------------------------------------------------------------------------------------------------- // super simple "component system" class GameObject; class Component; typedef std::vector<Component*> ComponentVector; typedef std::vector<GameObject*> GameObjectVector; // Component base class. Knows about the parent game object, and has some virtual methods. class Component { public: Component() : m_GameObject(nullptr) {} virtual ~Component() {} virtual void Start() {} virtual void Update(double time, float deltaTime) {} const GameObject& GetGameObject() const { return *m_GameObject; } GameObject& GetGameObject() { return *m_GameObject; } void SetGameObject(GameObject& go) { m_GameObject = &go; } bool HasGameObject() const { return m_GameObject != nullptr; } private: GameObject* m_GameObject; }; // Game object class. Has an array of components. class GameObject { public: GameObject(const std::string&& name) : m_Name(name) { } ~GameObject() { // game object owns the components; destroy them when deleting the game object for (auto c : m_Components) delete c; } // get a component of type T, or null if it does not exist on this game object template<typename T> T* GetComponent() { for (auto i : m_Components) { T* c = dynamic_cast<T*>(i); if (c != nullptr) return c; } return nullptr; } // add a new component to this game object void AddComponent(Component* c) { assert(!c->HasGameObject()); c->SetGameObject(*this); m_Components.emplace_back(c); } void Start() { for (auto c : m_Components) c->Start(); } void Update(double time, float deltaTime) { for (auto c : m_Components) c->Update(time, deltaTime); } private: std::string m_Name; ComponentVector m_Components; }; // The "scene": array of game objects. static GameObjectVector s_Objects; // Finds all components of given type in the whole scene template<typename T> static ComponentVector FindAllComponentsOfType() { ComponentVector res; for (auto go : s_Objects) { T* c = go->GetComponent<T>(); if (c != nullptr) res.emplace_back(c); } return res; } // Find one component of given type in the scene (returns first found one) template<typename T> static T* FindOfType() { for (auto go : s_Objects) { T* c = go->GetComponent<T>(); if (c != nullptr) return c; } return nullptr; }

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

यह कोड क्या करता है? खैर अच्छा नहीं

संक्षेप में, यह कोड भाषा की एक मौजूदा विशेषता को फिर से लागू करता है - एक रनटाइम लाइब्रेरी के रूप में रचना , और भाषा की विशेषता के रूप में नहीं। आप इसकी कल्पना कर सकते हैं जैसे कि कोड वास्तव में इस धातु भाषा को निष्पादित करने के लिए C ++ और एक वर्चुअल मशीन (VM) के शीर्ष पर एक नया मेटलंगेज बना रहे थे। अरस डेमो गेम में, इस कोड की आवश्यकता नहीं है ( हम इसे जल्द ही पूरी तरह से हटा देंगे! ) और केवल 10 बार खेल के प्रदर्शन को कम करने के लिए कार्य करता है।

लेकिन वह वास्तव में क्या करता है? यह " E ntity / C omponent system" ( कभी-कभी " E ntity / C omponent system" नामक किसी कारण से) की अवधारणा है, लेकिन यह " E ntity C " की अवधारणा से बिल्कुल अलग है omponent S ystem "(" एंटिटी-कंपोनेंट-सिस्टम ") ( जो स्पष्ट कारणों के लिए कभी भी" E ntity C omponent S ystem systems ) नहीं कहलाता है । यह "EC" के कई सिद्धांतों को औपचारिक रूप देता है:

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

2000 के दशक में एक समान अवधारणा बहुत लोकप्रिय थी, और इसकी सीमाओं के बावजूद, यह तब और आज दोनों के अनगिनत खेल बनाने के लिए पर्याप्त रूप से लचीला हो गया।

हालाँकि, इसकी आवश्यकता नहीं है। आपकी प्रोग्रामिंग भाषा में पहले से ही भाषा की एक विशेषता के रूप में रचना के लिए समर्थन है - इसे एक्सेस करने के लिए फूला हुआ अवधारणा की कोई आवश्यकता नहीं है ... क्यों, फिर, क्या ये अवधारणाएं मौजूद हैं? खैर, ईमानदार होने के लिए, वे आपको रनटाइम पर गतिशील रचना करने की अनुमति देते हैं। कोड में GameObject प्रकारों को परिभाषित करने के बजाय, आप उन्हें डेटा फ़ाइलों से लोड कर सकते हैं। और यह बहुत सुविधाजनक है, क्योंकि यह गेम / स्तर के डिजाइनरों को अपने प्रकार की वस्तुओं को बनाने की अनुमति देता है ... हालांकि, अधिकांश गेम प्रोजेक्ट्स में बहुत कम डिजाइनर और सचमुच प्रोग्रामर की एक पूरी सेना होती है, इसलिए मैं तर्क दूंगा कि यह एक महत्वपूर्ण अवसर है। इससे भी बदतर, यह एकमात्र तरीका नहीं है जब आप किसी रचना को रनटाइम पर लागू कर सकते हैं! उदाहरण के लिए, एकता C # को अपनी "स्क्रिप्टिंग भाषा" के रूप में उपयोग करती है, और कई अन्य खेल इसके विकल्पों का उपयोग करते हैं, उदाहरण के लिए, Lua - डिजाइनरों के लिए एक सुविधाजनक उपकरण ऐसी फूला हुआ अवधारणा की आवश्यकता के बिना नए गेम ऑब्जेक्ट्स को परिभाषित करने के लिए C # / Lua कोड उत्पन्न कर सकता है! हम अगली पोस्ट में इस "सुविधा" को फिर से जोड़ेंगे, और इसे बनाएंगे ताकि यह हमारे प्रदर्शन में दस गुना कमी न करे ...

आइए OOD के अनुसार इस कोड का मूल्यांकन करें:

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

हालांकि, वह डीआईपी बनाए रखने में इतना अच्छा नहीं है - कई घटकों को एक-दूसरे का प्रत्यक्ष ज्ञान है।

तो, ऊपर दिखाए गए सभी कोड वास्तव में हटाए जा सकते हैं। यह पूरी संरचना। GameObject को डिलीट करें (अन्य फ्रेमवर्क में एंटिटी भी कहा जाता है), कंपोनेंट निकालें, फाइंडऑफटाइप हटाएं। यह एक बेकार वीएम का हिस्सा है जो OOD सिद्धांतों का उल्लंघन करता है और हमारे खेल को बहुत धीमा कर देता है।

संरचना के बिना रचना (यानी प्रोग्रामिंग भाषा की सुविधाओं का उपयोग करके)

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

यहां वह कमेटी है जिसने एंटिटी / कंपोनेंट फ्रेमवर्क को हटाया: https://github.com/hodgman/dod-playground/commit/f42290d0217d700dea2ed002f2f3b1dcbe8c27c

यहाँ स्रोत कोड का मूल संस्करण है: https://github.com/hodgman/dod-playground/blob/3529f232510c95f53112bbfff87df6bbc6aa1fae-source/game.cpp

यहाँ स्रोत कोड का संशोधित संस्करण है: https://github.com/hodgman/dod-playground/blob/f42290d0217d700dea2ed002f2f3b1dc45e8d27c/source/game.cpp

परिवर्तनों के बारे में संक्षेप में:

हटाया गया: प्रत्येक घटक प्रकार से "सार्वजनिक घटक"।
प्रत्येक प्रकार के घटक के लिए एक निर्माता जोड़ा गया।
- OOD मुख्य रूप से एक वर्ग के राज्य को घेरने के बारे में है, लेकिन चूंकि ये कक्षाएं इतनी छोटी / सरल हैं, इसलिए छिपाने के लिए कुछ विशेष नहीं है: एक इंटरफ़ेस डेटा का विवरण है। हालांकि, मुख्य कारणों में से एक है कि एनकैप्सुलेशन मुख्य स्तंभ है, यह हमें वर्ग के अपरिवर्तनीयों की निरंतर सच्चाई की गारंटी देता है ... या यदि एरियर टूट गया है, तो आपको त्रुटि खोजने के लिए एन्कैप्सुलेटेड कार्यान्वयन कोड की जांच करने की आवश्यकता है। इस कोड उदाहरण में, एक साधारण अक्रियाशील को लागू करने के लिए कंस्ट्रक्टरों को जोड़ने के लायक है - सभी मूल्यों को आरंभीकृत करना चाहिए।
मैंने अपने नाम रखने के लिए बहुत सामान्य "अपडेट" विधियों का नाम बदल दिया, जो वे वास्तव में करते हैं, यह दर्शाते हैं - MoveComponent के लिए UpdatePosition और AvoidComponent के लिए ResolveCollisions।
मैंने कोड के तीन हार्ड-कोड किए गए ब्लॉक निकाले, जो एक टेम्प्लेट / प्रीफ़ैब से मिलता-जुलता था - वह कोड जो गेमऑबजेक्ट बनाता है जिसमें विशिष्ट प्रकार के कंपोनेंट होते हैं, और इसे तीन C ++ क्लासेस से बदल दिया जाता है।
हटाए गए एंटीपैटर्न "वर्चुअल शून्य अपडेट"।
"सेवा लोकेटर" टेम्पलेट के माध्यम से एक दूसरे की तलाश करने वाले घटकों के बजाय, खेल निर्माण के दौरान उन्हें स्पष्ट रूप से बांधता है।

वस्तुएं

इसलिए, इस "वर्चुअल मशीन" कोड के बजाय:

  // create regular objects that move for (auto i = 0; i < kObjectCount; ++i) { GameObject* go = new GameObject("object"); // position it within world bounds PositionComponent* pos = new PositionComponent(); pos->x = RandomFloat(bounds->xMin, bounds->xMax); pos->y = RandomFloat(bounds->yMin, bounds->yMax); go->AddComponent(pos); // setup a sprite for it (random sprite index from first 5), and initial white color SpriteComponent* sprite = new SpriteComponent(); sprite->colorR = 1.0f; sprite->colorG = 1.0f; sprite->colorB = 1.0f; sprite->spriteIndex = rand() % 5; sprite->scale = 1.0f; go->AddComponent(sprite); // make it move MoveComponent* move = new MoveComponent(0.5f, 0.7f); go->AddComponent(move); // make it avoid the bubble things AvoidComponent* avoid = new AvoidComponent(); go->AddComponent(avoid); s_Objects.emplace_back(go); }

अब हमारे पास नियमित C ++ कोड है:

 struct RegularObject { PositionComponent pos; SpriteComponent sprite; MoveComponent move; AvoidComponent avoid; RegularObject(const WorldBoundsComponent& bounds) : move(0.5f, 0.7f) // position it within world bounds , pos(RandomFloat(bounds.xMin, bounds.xMax), RandomFloat(bounds.yMin, bounds.yMax)) // setup a sprite for it (random sprite index from first 5), and initial white color , sprite(1.0f, 1.0f, 1.0f, rand() % 5, 1.0f) { } }; ... // create regular objects that move regularObject.reserve(kObjectCount); for (auto i = 0; i < kObjectCount; ++i) regularObject.emplace_back(bounds);

एल्गोरिदम

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

  // go through all objects for (auto go : s_Objects) { // Update all their components go->Update(time, deltaTime);

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

इसके बजाय, हमने एक अधिक स्पष्ट मुख्य लूप बनाया, जो नियंत्रण प्रवाह की समझ को बहुत सरल करता है (इसमें डेटा प्रवाह अभी भी बाधित है, लेकिन हम इसे निम्नलिखित कमियों में ठीक कर देंगे )।

  // Update all positions for (auto& go : s_game->regularObject) { UpdatePosition(deltaTime, go, s_game->bounds.wb); } for (auto& go : s_game->avoidThis) { UpdatePosition(deltaTime, go, s_game->bounds.wb); } // Resolve all collisions for (auto& go : s_game->regularObject) { ResolveCollisions(deltaTime, go, s_game->avoidThis); }

इस शैली का नुकसान यह है कि खेल में जोड़े गए प्रत्येक नए प्रकार के ऑब्जेक्ट के लिए, हमें मुख्य लूप में कई पंक्तियों को जोड़ना होगा। मैं इस श्रृंखला से बाद की पोस्ट में इस पर वापस लौटूंगा।

उत्पादकता

कई विशाल OOD उल्लंघन हैं, एक संरचना का चयन करते समय कुछ बुरे निर्णय किए जाते हैं, और अनुकूलन के लिए कई अवसर हैं, लेकिन मैं उन्हें श्रृंखला के अगले पोस्ट में प्राप्त करूंगा। हालाँकि, पहले से ही इस स्तर पर यह स्पष्ट है कि "सही OOD" वाला संस्करण लगभग मैच या अंतिम "ECS" कोड को प्रस्तुति के अंत से जीतता है ... और हमने केवल खराब छद्म-OOP कोड लिया और सिद्धांतों का पालन किया। OOP (और कोड की सौ लाइनें भी हटा दी गईं)!

अगले चरण

यहाँ मैं मुद्दों की एक अधिक व्यापक श्रेणी पर विचार करना चाहता हूं, जिसमें शेष OOD समस्याओं को हल करना, अपरिवर्तनीय वस्तुओं ( एक कार्यात्मक शैली में प्रोग्रामिंग ) और वे फायदे जो वे डेटा प्रवाह, संदेश पारित करने, हमारे OOD कोड में DOD तर्क लागू करने के बारे में चर्चा कर सकते हैं। OOD कोड में प्रासंगिक ज्ञान लागू करना, "संस्थाओं" के इन वर्गों को हटाना जो हमने समाप्त किए, और केवल शुद्ध घटकों का उपयोग करते हुए, घटकों को जोड़ने के लिए विभिन्न शैलियों का उपयोग किया (बिंदुओं की तुलना करते हुए) वास्तविक दुनिया से ले जाने के) कंटेनरों के घटकों की जिम्मेदारी, ईसीएस-संशोधन संस्करण बेहतर अनुकूलन, साथ ही आगे अनुकूलन के लिए, रिपोर्ट Aras (जैसे बहु सूत्रण / SIMD) के रूप में में उल्लेख नहीं किया। आदेश अनिवार्य रूप से यह नहीं होगा, और शायद मैं उपरोक्त सभी पर विचार नहीं करूंगा ...

इसके अलावा

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

OOP मर चुका है, लंबे समय तक रहने वाला OOP है