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