2012-04-09 12 views
9

मैं एक सिम्युलेटर लिख रहा हूं जिसमें कई इंटरफेस हैं जो सभी अनुरूपित वस्तुओं को लागू करते हैं। Entity इंटरफ़ेस में विधियां हैं जिनके पास सभी ऑब्जेक्ट्स होना चाहिए, जैसे आईडी पुनर्प्राप्ति और ऑब्जेक्ट के राज्य के लिए समय चरण को आगे बढ़ाना। CollidableEntity बढ़ाता है, और वॉल्यूम और स्थिति के साथ कुछ भी प्रस्तुत करता है जिसे टकराव का पता लगाने एल्गोरिदम चलाने पर विचार किया जाना चाहिए। FieldEntity बढ़ाता है, और किसी भी स्थान को किसी मान के लिए मानचित्रित करता है; इनका उपयोग चुंबकीय क्षेत्रों जैसी चीजों को मॉडल करने के लिए किया जाता है जो दुनिया में प्रवेश करते हैं लेकिन उनके पास कोई मात्रा या भौतिक रूप नहीं है। RigidBody एक कक्षा है जो Collidable लागू करती है और कठोर-शरीर गतिशीलता एल्गोरिदम प्रदान करती है। मेरे पास World कक्षा है जो सभी Entities का प्रबंधन करती है और इसमें सिम्युलेटर की घड़ी को आगे बढ़ाने और दुनिया को विभाजित करने के तरीके हैं ताकि टकराव का पता लगाने में अधिक कुशलता हो सके।इंटरफ़ेस के कार्यान्वयन को संग्रहीत करने और विशिष्ट कार्यान्वयन को पुनर्प्राप्त करने के लिए एक अच्छा पैटर्न क्या है?

मेरी समस्या में उपप्रकार World से पुनर्प्राप्त करना शामिल है। मूल रूप से, World में अभी तक Entities का नक्शा आईडी के द्वारा किया गया था, और Field या RigidBody से छुटकारा पाने के लिए नक्शे के बाहर Entity को पकड़ लेंगे और instanceof वांछित उप प्रकार के लिए एक कास्ट चेक करें। मुझे अच्छी तरह से पता है कि instanceof उपयोग पर फंसे हुए हैं, इसलिए, मैंने एक और दृष्टिकोण की कोशिश की।

वर्तमान में, मेरे पास प्रत्येक इंटरफ़ेस के लिए World के भीतर अलग-अलग मानचित्र हैं। उदाहरण के लिए, Collidables के साथ-साथ सभी Entities के लिए मानचित्र के लिए एक मानचित्र है। addCollidable() विधि दोनों मानचित्रों में जोड़ दी जाएगी, और getCollidable() केवल Collidable मानचित्र से पुनर्प्राप्त होगा। यह instanceof से बचाता है, लेकिन यह अभी भी मुझे खराब डिजाइन की तरह लगता है। यदि मैं Entity का विस्तार करने के लिए एक और इंटरफ़ेस का सपना देखता हूं, तो मुझे World और संबंधित विधियों में एक और मानचित्र की आवश्यकता होगी।

मुझे लगता है कि यह समस्या बहुत अस्पष्ट नहीं है, तो आमतौर पर इस स्थिति में क्या किया जाता है?

संपादित

मैं नहीं मानता कि आगंतुक पैटर्न यहाँ काम करेंगे, के रूप में आगंतुक आप ठोस प्रकार पर प्रेषण करने के लिए अनुमति देता है, और मेरे पुनर्प्राप्ति तरीकों के कुछ इंटरफ़ेस प्रकार पुनः प्राप्त करने की जरूरत है। उदाहरण के लिए, WorldRigidBodies और अन्य ऐसे ठोस वर्गों को पुनर्प्राप्त करने के लिए केवल आवश्यक विधियों के लिए विज़िटर काम करेगा, लेकिन मैं ऐसी विधि नहीं बना सकता जो आगंतुक के साथ सभी Collidables पुनर्प्राप्त करे।

+2

आपके पास कुछ हो सकता है जैसे <<टी एंटीटी> टी getEntityFromMap (Clase क्लैज) बढ़ाता है, 'यह विधि' कोलिडेबल्स 'मानचित्र की आवश्यकता को हटा देती है, और आप केवल' getEntityFromMap (Entity.class) 'के लिए पूछते हैं। अपने सबसे सामान्य मामले में इकाई, और .... –

उत्तर

1

यहां आप जो भी उपयोग कर सकते हैं वह विज़िटर पैटर्न है, विज़िटर पैटर्न पर यह ट्यूटोरियल आपके समान समस्या के विरुद्ध इसका उपयोग करता है। http://www.youtube.com/watch?v=KSEyIXnknoY

+0

यह मेरी जरूरत के करीब है, लेकिन दुर्भाग्यवश आगंतुक ठोस प्रकारों पर प्रेषित करता है, और मुझे सार/इंटरफ़ेस प्रकारों के साथ-साथ ठोस प्रकारों पर प्रेषण करने की क्षमता की आवश्यकता होती है। – derefed

0

यह मेरे लिए प्रतीत होता है कि आप अपने विश्व स्तर में कोलिडबेल के लिए एक अतिरिक्त क्षेत्र का उपयोग करते हैं, क्योंकि यह डेटा का एक विशेष सबसेट है, जिसके लिए विशेष हैंडलिंग की आवश्यकता होती है।

केवल एक चीज मैं बदल जाएगा (ज्यादातर व्यक्तिगत स्वाद की वजह से) हालांकि, List<Collidable> प्रकार के रूप में, उपयोग कर रहा है, क्योंकि अपनी आवश्यकताओं के लिए - टक्कर जांच के लिए उनमें से सभी के माध्यम से पुनरावृत्ति - एक सूची एक तेजी से & अधिक हल्के दृष्टिकोण है।

+0

मेरे पास यह सवाल यह है कि जब 'ऑब्जेक्ट' को लागू करने के लिए 'ऑब्जेक्ट' को 'वर्ल्ड' में जोड़ा जाता है, तो 'विश्व' यह कहने में सक्षम होगा कि 'ओबीजे' को 'सूची ' में इस्तेमाल किए बिना इस्तेमाल किया जाना चाहिए एक 'exampleof' जांच? – derefed

+0

मुझे लगता है कि आपके पास पहले से ही 'World.addEntity (Entity newEntity)' जैसी कुछ है। बस 'World.addEntity (Collidable newCollidable)' जोड़ें, इसे उचित रूप से कार्यान्वित करें, और बाकी को जावा को संभालें। – KJP

1

instanceof का उपयोग करना है, क्योंकि यह अक्सर संदर्भों में दिखाई देता है, जहां यह अधूरा कैप्सूलीकरण पर संकेत पर सिकोड़ी है। उदाहरण के लिए, instanceof कभी-कभी विभिन्न प्रकार की वस्तुओं के बीच अंतर करने के लिए उपयोग किया जाता है और फिर उनके प्रकार के आधार पर उन पर काम करता है।ऐसा करने का एक क्लीनर तरीका कोड को वस्तुओं के संबंधित वर्गों में रखना और इसके बजाय polymorphism का उपयोग करना है। तो, instanceof का उपयोग करके instanceof का उपयोग करके खुद से पूछें कि instanceof का वर्तमान उपयोग वैध हो सकता है?

दूसरे शब्दों में: यह कोड है कि इसी इकाई वर्ग में इकाई के प्रकार पर निर्भर करता है स्थानांतरित करने के लिए संभव है? (बेशक , एक बार आप एक निष्कर्ष यह प्रलेखित किया जाना चाहिए, चीजों को बदल सकते हैं के रूप में। तक पहुँचने) Btw

मुझे लगता है कि आप आसानी से आप एक Map<Class,List<Entity>> का उपयोग करके वर्तमान डिजाइन सामान्यीकरण कर सकते हैं, जो आप करने की अनुमति होगी इकाई की सूचियों को मनमानी संख्या के लिए रखें। आपके पास एक सरणी Class[] types = {...} भी हो सकती है जिसमें सभी प्रकार शामिल हैं जिन्हें प्रतिष्ठित करने की आवश्यकता है। अब आपको instanceof ऑपरेटर को for लूप में add/removeEntity(...) विधियों में केवल एक ही आवश्यकता है, जो सभी प्रकारों के माध्यम से चलने की आवश्यकता होगी जिन्हें सभी विशिष्ट सूचियों में/से अलग करने के लिए अलग किया जाना चाहिए।

संबंधित मुद्दे