उनकी चिंता यह थी कि बड़ी संख्या में कक्षाएं एक रखरखाव दुःस्वप्न में बदल जाएंगी। मेरा विचार था कि इसका सटीक विपरीत प्रभाव होगा।
मैं आपके मित्र के पक्ष में हूं, लेकिन यह हमारे डोमेन और समस्याओं और डिजाइनों के प्रकारों से जुड़ा हो सकता है, जिनसे हम निपटते हैं और विशेष रूप से भविष्य में बदलाव के लिए किस प्रकार की चीजों की आवश्यकता होती है। विभिन्न समस्याओं, विभिन्न समाधान। मैं सही या गलत में विश्वास नहीं करता, बस प्रोग्रामर सबसे अच्छा तरीका खोजने की कोशिश कर रहे हैं जो वे अपने विशेष डिजाइन समस्याओं को सबसे अच्छा हल कर सकते हैं। मैं वीएफएक्स में काम करता हूं जो गेम इंजन के विपरीत नहीं है।
लेकिन मेरे लिए समस्या यह है कि मैं कम से कम एक ठोस-अनुरूप वास्तुकला (इसे COM- आधारित था) के रूप में कुछ हद तक कहा जा सकता है के साथ संघर्ष किया, गंभीर रूप से "बहुत सारे वर्गों" या "बहुत अधिक कार्यों" के रूप में उबला हो सकता है आपका मित्र वर्णन कर सकता है। मैं विशेष रूप से कहूंगा, "बहुत सारे इंटरैक्शन, बहुत सी जगहें जो संभवतः दुर्व्यवहार कर सकती हैं, बहुत सी जगहें जो संभवतः दुष्प्रभाव पैदा कर सकती हैं, बहुत सी जगहें जिन्हें बदलने की आवश्यकता हो सकती है, और बहुत से स्थान जो हम सोचते हैं कि वे नहीं कर सकते हैं। । "
हमारे पास एक उप-सार (और शुद्ध) इंटरफेस है जो उप-प्रकारों के एक बोटलोड द्वारा कार्यान्वित किया जाता है, जैसे कि (ईसीएस लाभ के बारे में बात करने के संदर्भ में यह चित्र बनाया गया है, नीचे-बाईं टिप्पणी की उपेक्षा करें):
जहां एक गति इंटरफ़ेस या एक दृश्य नोड इंटरफ़ेस सैकड़ों उपप्रकारों द्वारा लागू किया जा सकता है: रोशनी, कैमरे, जाल, भौतिकी सॉल्वर, शेड्स, बनावट, हड्डियों, आदिम आकार, घटता, आदि (और अक्सर कई प्रकार के प्रत्येक होते हैं) )। और वास्तव में समस्या यह थी कि वे डिजाइन इतने स्थिर नहीं थे। हमारे पास बदलती आवश्यकताएं थीं और कभी-कभी स्वयं को बदलने के लिए इंटरफेस को बदलना पड़ता था, और जब आप 200 उपप्रकारों द्वारा लागू किए गए सार इंटरफ़ेस को बदलना चाहते हैं, तो यह एक बहुत महंगा बदलाव है। हमने इस बात को कम करना शुरू कर दिया कि बीच में अमूर्त आधार वर्गों का उपयोग करके इस तरह के डिजाइन परिवर्तनों की लागत कम हो गई, लेकिन वे अभी भी महंगे थे।
इसलिए वैकल्पिक रूप से मैंने गेमिंग उद्योग में आमतौर पर उपयोग की जाने वाली इकाई-घटक प्रणाली वास्तुकला की खोज शुरू की। इस तरह से सब कुछ बदल गया:
और वाह! स्थिरता के संदर्भ में ऐसा अंतर था। निर्भरता अब अमूर्तता की ओर नहीं बढ़ी बल्कि डेटा (घटकों) की । और मेरे मामले में कम से कम, डेटा बहुत अधिक स्थिर था और बदलती आवश्यकताओं के बावजूद डिजाइन के संदर्भ में सही होने के लिए आसान है (हालांकि हम एक ही डेटा के साथ क्या कर सकते हैं लगातार बदलती आवश्यकताओं के साथ बदल रहा है)।
इसके अलावा, क्योंकि ईसीएस में इकाइयां विरासत के बजाय संरचना का उपयोग करती हैं, उन्हें वास्तव में कार्यक्षमता रखने की आवश्यकता नहीं होती है। वे केवल अनुरूप "घटकों के कंटेनर" हैं। इसने इसे इतना अनुरूप बनाया कि 200 उपप्रकारों ने एक गति इंटरफ़ेस को लागू किया 200 इकाई उदाहरण (अलग कोड के साथ अलग प्रकार नहीं) जो बस एक गति घटक (जो गति के साथ जुड़े डेटा के अलावा कुछ भी नहीं है ) को संग्रहीत करते हैं । A PointLightअब एक अलग वर्ग / उपप्रकार नहीं है। यह एक वर्ग नहीं है। यह एक इकाई का एक उदाहरण है जो सिर्फ अंतरिक्ष (गति) और बिंदु रोशनी के विशिष्ट गुणों से संबंधित कुछ घटकों (डेटा) को जोड़ती है। उनके साथ जुड़ी एकमात्र कार्यक्षमता सिस्टम के अंदर है, जैसेRenderSystem, जो दृश्य में प्रकाश घटकों के लिए लगता है कि यह निर्धारित करने के लिए कि दृश्य को कैसे प्रस्तुत किया जाए।
ईसीएस दृष्टिकोण के तहत बदलती आवश्यकताओं के साथ, अक्सर उस डेटा पर काम करने वाले एक या दो सिस्टम को बदलने या केवल एक नई प्रणाली को पेश करने की आवश्यकता होती है, या नए डेटा की आवश्यकता होने पर एक नए घटक को प्रस्तुत करना होता है।
इसलिए मेरे डोमेन के लिए कम से कम, और मैं लगभग निश्चित हूं कि यह हर किसी के लिए नहीं है, इसने चीजों को इतना आसान बना दिया क्योंकि निर्भरता स्थिरता की ओर बह रही थी (ऐसी चीजें जिन्हें अक्सर बदलने की आवश्यकता नहीं थी)। COM वास्तुकला में ऐसा नहीं था जब निर्भरता समान रूप से अमूर्तता की ओर बह रही थी। मेरे मामले में यह पता लगाना बहुत आसान है कि मोशन अपफ्रंट के लिए कौन सा डेटा आवश्यक है बजाय इसके कि आप इसके साथ क्या कर सकते हैं, जो अक्सर नई आवश्यकताओं के आते ही महीनों या वर्षों में बदल जाता है।
क्या ओओपी में ऐसे मामले हैं जहां कुछ या सभी ठोस सिद्धांत खुद को साफ करने के लिए उधार नहीं देते हैं?
ठीक है, क्लीन कोड मैं नहीं कह सकता क्योंकि कुछ लोग SOLID के साथ स्वच्छ कोड की बराबरी करते हैं, लेकिन निश्चित रूप से कुछ ऐसे मामले हैं जहां डेटा को कार्यक्षमता से अलग किया जाता है जैसा कि ECS करता है, और डेटा के प्रति अमूर्तता से दूर निर्भरता को निश्चित रूप से चीजों को बहुत आसान बना सकता है परिवर्तन, स्पष्ट युग्मन कारणों के लिए, यदि डेटा अमूर्त की तुलना में बहुत अधिक स्थिर होने जा रहा है। निश्चित रूप से डेटा पर निर्भरता आक्रमणकारियों को बनाए रखना मुश्किल बना सकती है, लेकिन ईसीएस कम से कम उस सिस्टम संगठन के साथ कम करने के लिए जाता है जो किसी भी प्रकार के घटक तक पहुंचने वाले सिस्टम की संख्या को कम करता है।
यह जरूरी नहीं है कि निर्भरता अमूर्तता की ओर प्रवाहित होनी चाहिए क्योंकि डीआईपी सुझाव देगा; निर्भरता उन चीजों की ओर प्रवाहित होनी चाहिए जो भविष्य में बदलाव की आवश्यकता की संभावना नहीं है। यह सभी मामलों में सार हो सकता है या नहीं (यह निश्चित रूप से मेरा नहीं था)।
- हां, ओओपी डिजाइन सिद्धांत मौजूद हैं जो एसओएलआईडी के साथ आंशिक रूप से संघर्ष करते हैं
- हां, ओओपी डिजाइन सिद्धांत मौजूद हैं जो एसओएलआईडी के साथ पूरी तरह से संघर्ष करते हैं।
मुझे यकीन नहीं है कि ईसीएस वास्तव में ओओपी का स्वाद है। कुछ लोग इसे इस तरह से परिभाषित करते हैं, लेकिन मैं इसे युग्मन विशेषताओं और कार्यक्षमता (सिस्टम) से डेटा (घटकों) के पृथक्करण और डेटा एनकैप्सुलेशन की कमी के साथ स्वाभाविक रूप से अलग देखता हूं। अगर इसे OOP का एक रूप माना जाए, तो मुझे लगता है कि यह SOLID (कम से कम SRP के सख्त विचारों, खुले / बंद, liskov प्रतिस्थापन, और DIP) के साथ संघर्ष में बहुत अधिक है। लेकिन मुझे उम्मीद है कि यह एक मामले और डोमेन का एक उचित उदाहरण है जहां एसओएलआईडी के सबसे बुनियादी पहलू हैं, कम से कम क्योंकि लोग आमतौर पर उन्हें एक अधिक पहचानने योग्य ओओपी संदर्भ में व्याख्या करेंगे, इसलिए लागू नहीं हो सकता है।
नन्हा वर्ग
मैं अपने एक खेल की वास्तुकला की व्याख्या कर रहा था, जो मेरे दोस्त के आश्चर्य में था, जिसमें कई छोटी कक्षाएं और कई अमूर्त परतें थीं। मैंने तर्क दिया कि यह सब कुछ एक ही जिम्मेदारी देने पर ध्यान केंद्रित करने और घटकों के बीच युग्मन को ढीला करने का परिणाम था।
ECS ने चुनौती दी है और मेरे विचारों को बहुत बदल दिया है। आपकी तरह, मुझे लगता था कि स्थिरता का बहुत ही विचार संभव चीजों के लिए सबसे सरल कार्यान्वयन है, जो कई चीजों का मतलब है, और इसके अलावा, कई अन्योन्याश्रित चीजें (भले ही अन्योन्याश्रितियों के बीच का अंतर हो)। यह सबसे अधिक समझ में आता है अगर आप केवल एक वर्ग या फ़ंक्शन पर ज़ूम कर रहे हैं, तो सबसे सरल, सरल कार्यान्वयन देखना चाहते हैं, और यदि हम एक नहीं देखते हैं, तो इसे रिफलेक्टर करें और हो सकता है कि यह आगे भी विघटित हो जाए। लेकिन यह याद रखना आसान हो सकता है कि परिणामस्वरूप बाहरी दुनिया के साथ क्या हो रहा है, क्योंकि किसी भी समय आप किसी भी चीज़ को अपेक्षाकृत जटिल रूप से 2 या अधिक चीजों में विभाजित करते हैं, उन 2 या अधिक चीजों को अनिवार्य रूप से एक दूसरे के साथ * (नीचे देखें) बातचीत करनी चाहिए रास्ता, या बाहर कुछ भी उन सभी के साथ बातचीत करने के लिए है।
इन दिनों मुझे लगता है कि किसी चीज की सादगी और कितनी चीजें हैं और कितनी सहभागिता की आवश्यकता है, के बीच एक संतुलनकारी कार्य है। एक ईसीएस में सिस्टम नहीं बल्कि गैर तुच्छ कार्यान्वयन के साथ मोटी तरह, डेटा पर संचालित करने के लिए हो जाते हैं PhysicsSystemया RenderSystemया GuiLayoutSystem। हालांकि, यह तथ्य कि एक जटिल उत्पाद की आवश्यकता होती है, उनमें से कुछ को वापस लेना आसान हो जाता है और पूरे कोडबेस के समग्र व्यवहार के बारे में तर्क करना आसान हो जाता है। वहां ऐसा कुछ है जो यह सुझाव दे सकता है कि यह कम, बल्कियर वर्गों (अभी भी यकीनन एकवचन जिम्मेदारी निभा रहा है) की तरफ झुकाव के लिए एक बुरा विचार नहीं हो सकता है, अगर इसका मतलब है कि कम कक्षाएं बनाए रखने और इसके बारे में तर्क करने के लिए, और कम बातचीत के दौरान प्रणाली।
सहभागिता
मैं कहता हूं कि "युग्मन" के बजाय "इंटरैक्शन" (हालांकि बातचीत को कम करने का मतलब दोनों को कम करना है), क्योंकि आप दो ठोस वस्तुओं को हटाने के लिए सार का उपयोग कर सकते हैं, लेकिन वे अभी भी एक दूसरे से बात करते हैं। इस अप्रत्यक्ष संचार की प्रक्रिया में वे अभी भी दुष्प्रभाव पैदा कर सकते हैं। और अक्सर मुझे लगता है कि सिस्टम की शुद्धता के बारे में तर्क करने की मेरी क्षमता "युग्मन" से अधिक इन "इंटरैक्शन" से संबंधित है। बातचीत को कम से कम करना मेरे लिए चीजों को बहुत आसान बना देता है और हर चीज के बारे में एक पक्षी की नजर से। इसका मतलब है कि चीजें एक-दूसरे से बिल्कुल भी बात नहीं करती हैं, और उस अर्थ से, ईसीएस वास्तव में "इंटरैक्शन" को कम से कम करने के लिए जाता है, और न केवल युग्मन के लिए, न्यूनतम के बार में (कम से कम मैं हेवन)
इसने कहा, यह कम से कम आंशिक रूप से मुझे और मेरी व्यक्तिगत कमजोरियों को हो सकता है। मैंने अपने लिए सबसे बड़ी बाधा खड़ी कर दी है, ताकि मैं बड़े पैमाने पर सिस्टम बना सकूं और फिर भी आत्मविश्वास से उनके बारे में तर्क कर सकूं, उनके माध्यम से नेविगेट कर सकूं, और महसूस कर सकूं कि मैं एक पूर्वानुमानित फैशन में कहीं भी कोई भी संभावित वांछित बदलाव कर सकता हूं, वह है राज्य और संसाधन प्रबंधन दुष्प्रभाव। यह सबसे बड़ी बाधा है जो उठने लगती है क्योंकि मैं LOC के हजारों-लाखों LOC से लेकर लाखों LOC तक लाखों LOC पर जाता हूँ, यहाँ तक कि उस कोड के लिए भी जिसे मैंने अपने दम पर पूरी तरह से लेखक किया था। अगर कोई चीज मुझे सब से ऊपर क्रॉल करने के लिए धीमा कर रही है, तो यह इस अर्थ में है कि मैं अब समझ नहीं पा रहा हूं कि एप्लिकेशन स्टेट, डेटा, साइड इफेक्ट्स के मामले में क्या हो रहा है। यह नहीं रोबोट समय है कि यह एक बदलाव करने की आवश्यकता है कि मुझे इतना धीमा कर देती है कि परिवर्तन के पूर्ण प्रभावों को समझने में असमर्थता अगर प्रणाली मेरे मन की क्षमता से परे बढ़ती है इसके बारे में तर्क करने के लिए। और बातचीत को कम करना, मेरे लिए, सबसे प्रभावी तरीका है कि उत्पाद को मेरे बिना व्यक्तिगत रूप से बहुत अधिक सुविधाओं के साथ विकसित करने की अनुमति देता है, इन चीजों से व्यक्तिगत रूप से अभिभूत हो जाता है, क्योंकि बातचीत को कम करने से कम से कम उन स्थानों की संख्या कम हो सकती है जो कर सकते हैं यहां तक कि संभवत: एप्लिकेशन स्थिति को बदलते हैं और साइड इफेक्ट्स को काफी हद तक प्रभावित करते हैं।
यह इस तरह से कुछ मोड़ सकता है (जहां आरेख में सब कुछ कार्यक्षमता है, और जाहिर है कि एक वास्तविक दुनिया का परिदृश्य कई, कई बार वस्तुओं की संख्या होगा, और यह "इंटरैक्शन" आरेख है, न कि एक युग्मन, एक युग्मन के रूप में। एक के बीच में सार होगा):
... इसके लिए जहां केवल सिस्टम में कार्यक्षमता है (नीले घटक अब केवल डेटा हैं, और अब यह एक युग्मन आरेख है):
और इस सब पर विचार उभर रहे हैं और शायद इन लाभों में से कुछ को एक अधिक अनुरूप ओओपी संदर्भ में फ्रेम करने का एक तरीका है जो एसओएलआईडी के साथ अधिक संगत है, लेकिन मुझे अभी तक डिजाइन और शब्द नहीं मिले हैं, और मुझे यह मिल गया है मुश्किल के बाद से शब्दावली मैं OOP से संबंधित सभी के आसपास फेंकने के लिए इस्तेमाल किया गया था। मैं यहाँ पर लोगों के उत्तरों के माध्यम से पढ़ने के बारे में जानने की कोशिश करता रहता हूँ और अपनी खुद की रूपरेखा बनाने की भी पूरी कोशिश करता हूँ, लेकिन ECS की प्रकृति के बारे में कुछ बातें बहुत दिलचस्प हैं जिन्हें मैं अपनी उंगली पर पूरी तरह से नहीं लगा पा रहा हूँ। अधिक व्यापक रूप से आर्किटेक्चर के लिए भी लागू हो सकता है जो इसका उपयोग नहीं करते हैं। मुझे यह भी उम्मीद है कि यह उत्तर एक ईसीएस पदोन्नति के रूप में बंद नहीं होगा! मुझे बस यह बहुत दिलचस्प लगता है क्योंकि ईसीएस डिजाइन करने से वास्तव में मेरे विचारों में काफी बदलाव आया है,