2010-05-19 23 views
22

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

मैं अब के लिए थोड़ा 2 डी गेम प्रोग्रामिंग कर रहा हूं लेकिन मुझे लगता है कि मेरा प्रश्न किसी भी गैर-छोटी परियोजना पर लागू होता है। सादगी के लिए मैं अपने खेल से उदाहरण प्रदान करूंगा।

मैं लाश के विभिन्न प्रकार है, लेकिन वे सभी एक ही गुण (एक्स, वाई, स्वास्थ्य, हमला आदि) तो मैं एक इंटरफ़ेस ज़ोंबी जो मैं WalkingZombie, RunningZombie TeleportingZombie आदि द्वारा लागू लिखा यह सबसे अच्छा है करने के लिए? क्या मैं अमूर्त वर्ग के साथ बेहतर हूं? या सुपर क्लास के साथ? (मैं आंशिक रूप से कार्यों को लागू करने योजना बना रहा हूँ नहीं - के बजाय एक इंटरफ़ेस के लिए मेरी पसंद की वजह एक सार वर्ग की) मैं एक वर्ग मुख्य चरित्र (उत्तरजीवी) का वर्णन है

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

मुझे आशा है कि इस प्रश्न को व्यक्तिपरक के रूप में रेट नहीं किया जाएगा क्योंकि मैंने सोचा था कि अनुभवी प्रोग्रामर इस तरह के विषय से असहमत नहीं होंगे क्योंकि इंटरफेस/सुपर क्लासेस/अमूर्त कक्षाओं के उपयोग तार्किक नियमों का पालन करते हैं और इस प्रकार यह केवल व्यक्तिगत नहीं है चुनाव।

+0

ज़ोंबी उदाहरण –

उत्तर

15

आप एक "अनुबंध" के रूप में एक इंटरफेस के बारे में सोच सकते हैं। आप विधियों के एक समूह को परिभाषित कर रहे हैं कि इस इंटरफेस को लागू करने वाले वर्गों को लागू करना होगा।

दूसरी ओर, एक अमूर्त वर्ग का उपयोग तब किया जाता है जब आपके पास कुछ कोड होता है जो उन सभी बाल वर्गों के लिए आम हो सकता है जिन्हें आप कार्यान्वित करना चाहते हैं। तो आपके पास आकार नामक एक अमूर्त वर्ग हो सकता है जिसमें कुछ सामान्य कोड हो, और आपके व्युत्पन्न वर्ग (मंडल, स्क्वायर इत्यादि) में आपके पास उन आकारों के लिए विशिष्ट कोड हो सकता है (getArea एक उदाहरण होगा)। लेकिन रंग की तरह कुछ आकार सभी आकारों के लिए आम हो सकता है, ताकि आप अपने आकार सारणी वर्ग में getColor विधि डाल सकें।

और आप दो विचारों को जोड़ सकते हैं। आप अमूर्त कक्षाएं कर सकते हैं जो इंटरफेस को लागू करते हैं, और यह आपको दोनों दुनिया के सर्वश्रेष्ठ प्रदान करता है।

ओओ में इन अवधारणाओं का बार-बार उपयोग किया जाता है, इसलिए उन्हें समझना महत्वपूर्ण है। आप अपने रास्ते पर अच्छी तरह से लग रहे हैं :)।

तो यदि आपकी ज़ोंबी कक्षा में कुछ सामान्य व्यवहार हैं जो सभी प्रकार के लाशों पर लागू होते हैं, तो यह एक अच्छा उम्मीदवार की तरह एक अमूर्त वर्ग की तरह लगता है। यदि आपके पास आपके गेम में अन्य वर्ण हैं (शायद UndeadMice या कुछ :)) तो आप एक इंटरफ़ेस (शायद GameCharacter इंटरफ़ेस) बनाने पर भी विचार कर सकते हैं। फिर आपके Zombie अमूर्त वर्ग और UndeadMouse अमूर्त वर्ग GameCharacter इंटरफ़ेस को लागू करेगा।

+0

+1 "अनुबंध" –

+0

प्रयोग करने के लिए धन्यवाद आप :) यह तय करना देने के लिए जो 'जवाब' हालांकि .. मैं विशेष रूप से इंटरफेस को लागू करने सार वर्गों के बारे में अपने विचार पसंद मुश्किल था, मोटे तौर पर साथ प्रकार के एक बहुत ही स्पष्ट संरचना प्रदान करता है उदाहरण के लिए हैंडलिंग के विभिन्न प्रकारों को संभालने की अनुमति देते हुए वही गुण। आप चीजों को कनेक्ट करने के लिए कैसे देखने में कठिनाई हो जाता है, यह कभी कभी कागज पर सामान को बाहर निकालने, या Microsoft Visio जैसे कुछ उपकरण का उपयोग करने में मदद करता है - फिर भी वास्तव में सब कुछ संबंधों आदि – Samuel

+1

@Samuel देखकर सही तरीके से कनेक्ट करने के लिए एक मुश्किल समय हो रही है। यह आपको कल्पना करने में मदद कर सकता है कि चीजें एक साथ कैसे फिट होती हैं ताकि आप अमूर्तता के उचित स्तर को डिज़ाइन कर सकें। – dcp

0

मुझे नहीं लगता कि आपके मामले में आपका इंटरफ़ेस और वर्ग संरचना वास्तविकता के साथ अच्छी तरह से संरेखित है। असल में, मेरा मानना ​​है (अगर मैं गलत हूं तो मुझे सही करें) कि प्रत्येक ज़ोंबी चल रहा है, चल रहा है, टेलीपोर्टिंग इत्यादि कहां है।

इसलिए, आपके पास ज़ोंबी क्लास या इंटरफ़ेस होना चाहिए और ज़ोंबी के राज्य को संशोधित करने वाले क्रियाएं होनी चाहिए। कार्रवाई शायद एक इंटरफ़ेस या एक अमूर्त वर्ग होगी, ताकि आप यह जानने के बिना ज़ोंबी में कोई भी क्रिया लागू कर सकें कि सटीक कार्रवाई क्या होती है (उदा। action.perform(zobie))।

यदि आपके पास तीन-पैर वाली ज़ोंबी और एक-सशस्त्र लाश जैसे विभिन्न प्रकार के लाश हैं, तो आप ज़ोंबी सामान को संभालने वाले विभिन्न वर्गों को लागू करना चाहते हैं, जैसे कि स्वयं को प्रदर्शित करना या राज्य परिवर्तनों को मान्य करना (उदाहरण के लिए एक विशेष ज़ोंबी की तरह टेलीपोर्ट किया जा सकता है)।

+0

के लिए +1 यह एक दिलचस्प सामाजिक प्रश्न होगा कि यह देखने के लिए कि किसी के जीवन के कितने घंटों के खिलाफ प्लॉट किए गए प्रकारों के बजाय 'चलने' 'चल रहे' और 'टेलीपोर्टिंग' की व्याख्या करने की संभावना है। सस्ते ज़ोंबी शूटर खेल के लिए :) – Affe

+0

खो क्यों मैं विभिन्न प्रकार था क्योंकि वे 1. स्थानांतरण और 2. प्रारंभ की अलग-अलग दृष्टिकोण है, चलते समय लाश स्क्रीन teleporting लाश आप और आप का दौरा पड़ने के पास दिखाई देते हैं में चलते है। वहाँ भी एक शराबी ज़ोंबी बेतरतीब ढंग से उच्च गति फेंकने की बोतलें (उदाहरण) – Samuel

+0

मैं देख रहा हूँ पर चारों ओर चल रहा हो सकता है, तो वे * * अलग ज़ोंबी प्रकार और नहीं कार्यों जो किसी भी ज़ोंबी द्वारा किया जा सकता है। इस मामले में अपने स्वयं के कार्यान्वयन होने पर आईएमएचओ ठीक होगा। – Lucero

0

आपके ज़ोंबी उदाहरण के संदर्भ में, इंटरफ़ेस अच्छा प्रदर्शन करेगा, जब तक कि आपके पास सामान्य कोड न हो जो आप सभी ज़ोंबी करना चाहते हैं।

आप एक Move विधि, करता है कि walkingzombies चलना, runningzombies चलाने, आदि हालांकि है, यदि आप ज़ोंबी के किसी भी प्रकार कुछ आम कर बनाने के लिए "चाल" चाहते कहो, तो इंटरफ़ेस कोड नकल करने आप मजबूर करने के लिए जा रहा है , क्योंकि आप एक शरीर को एक इंटरफ़ेस में नहीं डाल सकते हैं।

1

मैं के क्षेत्र एक्स, वाई, स्वास्थ्य, आदि परिभाषा ...

उत्तरजीवी वर्ग के लिए से बचने के लिए एक अमूर्त वर्ग के रूप में ज़ोंबी लिखा होता है, मैं बस सार्वजनिक कार्यों की घोषणा के लिए होता है प्रयोग की जाने वाली बाहर से। मैं कक्षा के शीर्ष पर सार्वजनिक कार्यों की घोषणा करता हूं। एक इंटरफेस घोषित करते समय केवल एक वर्ग लागू करने के लिए इसे बेकार रूप से बनाए रखने के लिए एक फ़ाइल जोड़ता है। इससे बचो।

+0

मैं एक फ़ाइल को एक रखरखाव समस्या जोड़ने के लिए कॉल नहीं करता। बाद में जब आप उस अतिरिक्त चीज़ को चाहते हैं जो आपको इंटरफ़ेस के साथ मिलती है लेकिन आपके पास कोई नहीं है और यह एक को रखने के लिए बहुत काम है, यह एक समस्या है। – JHollanti

+0

एक फ़ाइल कोई समस्या नहीं है, लेकिन यदि आप इसे व्यवस्थित तरीके से करते हैं तो आप उनमें से बहुत से समाप्त हो जाएंगे। आवश्यकता होने पर एक इंटरफ़ेस जोड़ना आज के आईडीई के साथ कोई बड़ा सौदा नहीं है। –

+0

मेरे लिए इंटरफ़ेस फ़ाइलें भी पूरे कार्यक्रम की संरचना को स्पष्ट रखने में मेरी सहायता करती हैं। एक्स, वाई, स्वास्थ्य के साथ अच्छा बिंदु, मैं आमतौर पर लाश के लिए सार कक्षाओं के साथ इंटरफ़ेस को लागू करने के ऊपर उल्लिखित विचार का उपयोग करूंगा, जिसमें एक सामान्य एक्स, वाई, स्वास्थ्य होगा। – Samuel

1

कोई भी सुपर/सार वर्गों से अधिक इंटरफेस के उपयोग के बारे में भी इससे सहमत हैं;)

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

और यदि आप वास्तव में इस सामान में हैं तो आप मिश्रणों को भी देखना चाहेंगे। यह ऐसा कुछ नहीं है जो जावा सीधे समर्थन करता है लेकिन इसके लिए बनाए गए पुस्तकालय हैं।

+1

यहोशू बलोच, स्प्रिंग ढांचे और मूल रूप से किसी को जो अधिक (कार्यान्वयन) वंशानुक्रम सभी पक्ष रचना -inheritance एकल (कार्यान्वयन) में लॉक हो जाता है नहीं चाहता है के पीछे लोग। यह बहुत सारे लोग हैं :) – SyntaxT3rr0r

+0

अनुमोदित, एक अच्छा मुद्दा है, लेकिन मैं इस विषय पर चर्चा शुरू नहीं कर रहा हूं;) दुनिया में पर्याप्त समय नहीं है। सामान्य व्यवहार के लिए – JHollanti

+0

, इसके बजाए रणनीति पैटर्न का उपयोग करें। इंटरफ़ेस ज़ोंबी को getMoveStrategy() विधि दें और zombie.getMoveStrategy()। Move() का उपयोग करके इसे कॉल करें। वहाँ एक HopStrategy, एक SlouchStrategy एक RunStrategy आदि जो पैरामीटर हो सकता था हो सकता है (उदाहरण के लिए एक घायल ज़ोंबी धीमी है, गुस्से में ज़ोंबी तेजी से आदि, वहाँ एक बहुत कुछ है है की अगर-तो-और कुछ रणनीति पैटर्न के बिना शामिल) –

3

हां, मुझे लगता है कि आप अमूर्त वर्गों पर इंटरफेस के साथ सही ट्रैक का नेतृत्व कर रहे हैं।

कोई भी ठोस ज़ोंबी जो आप बनाना चाहते हैं, उसमें चलने, चलाने या टेलीपोर्टिंग सुविधाओं का कोई संयोजन हो सकता है जिसे आप लागू करने की देखभाल करते हैं।

मुझे लगता है कि आधुनिक प्रोग्रामिंग सिद्धांत जितना संभव हो सके विरासत को हतोत्साहित करता है, क्योंकि यह लंबे समय तक पुन: प्रयोज्यता और लचीलापन को रोकता है। इसके बजाय, 'तंग युग्मन' के बिना लचीलापन प्राप्त करने के लिए इंटरफेस और संरचना का उपयोग करें।

विरासत के बिना कोड का पुन: उपयोग करने के लिए एक पद्धति, आप 'उत्तराधिकारी पर अनुग्रह संरचना' प्रतिमान लागू कर सकते हैं।

मुझे लगता है कि करने के लिए जोश बलोच की 'प्रभावी जावा' (2 संस्करण) "वर्तमान सोच" के रूप में लिया जा सकता है

http://books.google.com/books?id=ZZOiqZQIbRMC&pg=RA1-PA71&lpg=RA1-PA71&dq=%22Bloch%22+%22Effective+java:+programming+language+guide%22+&hl=de&sig=RxlDlRBWUvNAzsAFzqOcftrYI5E#v=onepage&q&f=false

तो तुम स्वतंत्र वर्ग के रूप में अपने सभी व्यवहार को लागू कर सकता है की तरह है ...,, और फिर कार्यान्वयन के माध्यम से प्रत्येक ज़ोंबी क्रियान्वयन का अपना संयोजन कार्यान्वित करें, & संरचना ..

आशा है कि & समझ में आता है ...

+0

हाँ, लेकिन क्या होगा यदि सभी लाशों को कुछ सामान्य करना चाहिए जब वे आगे बढ़ें? वे सभी को डुप्लिकेट कोड होना होगा, है ना? –

+1

@Lerxst: नहीं, यह संरचना का बिंदु है। आप सामान्य कार्यक्षमता का प्रतिनिधित्व करने वाले वर्ग के उदाहरण को "लपेटें" और उस कक्षा में सामान्य कॉल का प्रतिनिधित्व करेंगे।एकमात्र डुप्लिकेट कोड प्रतिनिधिमंडल कॉल होगा लेकिन यह प्रति पंक्ति एक पंक्ति है (आपकी प्रत्येक * XXX ज़ोंबी * कक्षा में)। एक लिपटे विषय पर प्रतिनिधियों को कॉल करना अच्छी आईडीई द्वारा स्वचालित रूप से किया जा सकता है। – SyntaxT3rr0r

+0

हाय लेरक्स्ट और विज़ार्ड मुझे लगता है कि विज़ार्ड ने कहा कि मैं क्या कहना चाहता हूं .. आम व्यवहार को सदस्य वर्ग में परिभाषित किया जाएगा, और प्रत्येक ज़ोंबी कार्यान्वयन इस 'चाल व्यवहार' सदस्य को सौंपेगा। निश्चित रूप से, आप बार-बार प्रतिनिधिमंडल कोड [एक-लाइनर] के साथ समाप्त होते हैं, अधिक कक्षाओं का उल्लेख नहीं करते हैं, लेकिन यह अधिक लचीलापन प्रदान करता है। उदाहरण के लिए, इस सामान्य व्यवहार का उपयोग अब 'मानव' द्वारा किया जा सकता है, बिना किसी ज़ोंबी से संबंधित सामान ले जाया जा सकता है। – laher

4

संदेह में, मैं जीओएफ प्रतिमान का पालन करना चुनता हूं।

Encapsulate क्या भिन्न होता है: - अपने ही वर्ग में अद्वितीय व्यवहार को परिभाषित करें। उपरोक्त उदाहरण को संदर्भित करने के लिए, अपनी अलग कक्षा में चलने, चलाने और टेलीपोर्टेशन के लिए व्यवहार लागू करें। इस तरह, बहुलक व्यवहार लागू किया जाता है।

इसके विपरीत, ** आम क्या है ** - पॉलिमॉर्फिक संघों में सामान्य व्यवहार को परिभाषित करने के लिए सार कक्षाओं का उपयोग करें। वस्तुओं के बीच संबंधों को डिजाइन करते समय मैं इन सिद्धांतों का उपयोग करता हूं।

1

मैं लाश के विभिन्न प्रकार है, लेकिन वे सभी एक ही गुण (एक्स, वाई, स्वास्थ्य, हमले आदि) है तो मैं एक अंतरफलक ज़ोंबी जो मैं WalkingZombie, RunningZombie TeleportingZombie आदि द्वारा लागू लिखा था यह वह जगह है करने के लिए सबसे अच्छी बात? क्या मैं अमूर्त वर्ग के साथ बेहतर हूं? या एक सुपर क्लास के साथ?

एक अमूर्त वर्ग आपके ज़ोंबी के लिए एक सुपर क्लास होगा। एक इंटरफेस कुछ हद तक अपने लाश के लिए एक सुपर क्लास (सुपर इंटरफेस?) होना चाहिए।

आम गुण आम संपत्तियों के लिए कम से कम एक सार आधार वर्ग का सुझाव देते हैं।

यकीन नहीं तो आप इस से क्या मतलब है -

(एक अंतरफलक के बजाय एक अमूर्त वर्ग के लिए मेरी पसंद की वजह मैं आंशिक रूप से कार्यों को लागू करने की योजना बना नहीं कर रहा हूँ)।

अगर आप राक्षसों (goblins, orcs, आदि) के विभिन्न प्रकार था आप व्यवहार इन कि विभिन्न आधार वर्ग के हैं चाहेगा करने के लिए आम मिल सकती है। यह एक इंटरफेस का सुझाव देगा।

मैं एक सार आधार वर्ग के साथ शुरू और देखो क्या कोड आपको बताता है के रूप में आप इसे लिखते हैं।

मैं एक वर्ग मुख्य चरित्र (उत्तरजीवी) का वर्णन है और यह बहुत बड़ी मैं , विभिन्न कार्यों के साथ एक अंतरफलक लिखना चाहते थे ताकि मैं आसानी से देख सकते हैं और साझा की संरचना कर सकते हैं के बाद से की है। क्या यह अच्छा अभ्यास है? या यह बस अंतरिक्ष की बर्बादी है और समय है?

आपके उत्तरजीवी को खिलाड़ी-चरित्र कहा जाता है (एक गैर-खिलाड़ी चरित्र के विपरीत - किसी ऐसे गेम में जो सामान्य रूप से आपके उत्तरजीवी पर हमला नहीं करेगा)।

अधिकांश खेलों राक्षस के कुछ प्रकार के रूप में इन चरित्र प्रकार के सभी का इलाज के बाद से वे सभी आम में कई गुण (स्वास्थ्य। जादू, खजाने, हथियार, आदि)

तो शायद यह है कि के लिए एक तर्क के और भी है होगा एक इंटरफेस।

देखें:

Using inheritance and polymorphism to solve a common game problem Class diagram examples for RPG (Role Playing Game) designing class hierarchy for typical characters in role playing game

0

मेरे विचार से आप बेहतर की, ठीक है, जीव सभी प्रकार के लिए एक सुपर वर्ग के रूप में प्राणी बुलाया सार वर्ग का उपयोग, और यह ज़ोंबी तक का है सभी प्रकार के लाश के लिए
और तुम भी एक अंतरफलक कारण है कि आप की जरूरत एक अमूर्त वर्ग है की आवश्यकता होगी .. क्या चीजें हैं जो एक प्राणी कर सकते हैं परिभाषित करने के लिए ..
शायद की तरह, चलना, या पंजा, या चीख ...
प्राणी की तत्कालता को अक्षम करने के लिए, आप यह नहीं जानना चाहते कि यह प्राणी क्या प्राणी है, है ना?

+0

तकनीकी बिंदु: यदि आप तत्काल अक्षम करना चाहते हैं, तो अमूर्त पर्याप्त नहीं है, आपको रचनाकारों को भी संरक्षित करना होगा, अन्यथा अनाम इस तरह की अज्ञातता: नई जीव() {}; संभव है। –

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