ऑब्जेक्ट्स कैसे डिज़ाइन करें?

Question

तो वस्तुओं की संरचना के कई तरीके हैं (मैं यहां ओओपी की बात कर रहा हूं)। प्रश्न के लिए, मैं ओओपी के क्लासिक "कार" उदाहरण का उपयोग करूंगा। असल में, मुझे कैसे पता चलेगा कि कार को ऑब्जेक्ट या कार के पहिये को ऑब्जेक्ट कब बनाना है, जब दोनों प्रोग्राम स्ट्रक्चर लक्ष्य पूरा करेंगे?

मैं ऑब्जेक्ट के हिस्सों को वर्गीकृत और वर्गीकृत कैसे कर सकता हूं यह निर्धारित करने के लिए कि वे सरल गुणों या किसी ऑब्जेक्ट के चर के रूप में बेहतर हैं या नहीं, या यदि उन्हें वास्तव में ऑब्जेक्ट होने की आवश्यकता है?

Answer 1

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

तो आप कैसे वस्तुओं को डिजाइन करने के बारे में जानते हैं? आप कैसे जानते हैं कि आपने सही किया है या नहीं? अंत परिणाम: क्या यह आपकी समस्या हल कर चुका है?

तो, कार उदाहरण के लिए, कुछ मॉडलों में एक कार गणना केवल एक पूर्णांक गणना हो सकती है, उदाहरण के लिए यातायात मॉडल में एक चौराहे के माध्यम से कार यातायात। ऐसे मॉडल में शायद ही कभी आप कारों के निर्माण, मॉडल या निर्माण के बारे में परवाह करते हैं, केवल संख्या। आप वाहन के प्रकार के बारे में सोच सकते हैं कि यह एक ट्रक या कार है (उदाहरण के लिए)। क्या आप कार या ट्रक के प्रकार के साथ एक वाहन वस्तु के रूप में मॉडल करते हैं? या सिर्फ अलग कारकाउंट और ट्रक की लंबाई लम्बाई?

संक्षिप्त उत्तर है: जो भी सबसे अच्छा काम करता है।

किसी वस्तु के लिए सामान्य परीक्षण या नहीं, क्या इसका व्यवहार है? याद रखें कि आखिरकार वस्तुओं = डेटा + व्यवहार।

तो तुम कह सकते हैं कि कारों निम्नलिखित राज्य है:

• पहियों के

  ;

• निलंबन की ऊंचाई;
• बाएं या दाएं ड्राइव;
• रंग;
• चौड़ाई;
• वजन;
• लंबाई;
• ऊंचाई;

• दरवाजे के;

• चाहे इसमें सूर्योदय हो;
• चाहे इसमें स्टीरियो, सीडी प्लेयर, एमपी 3 प्लेयर और/या सतनाव हो;
• पेट्रोल टैंक का आकार;
• सिलेंडरों की संख्या;

• टर्बो शुल्कों और/या ईंधन इंजेक्शन के;

• अधिकतम टोक़;
• अधिकतम ब्रेक-हॉर्स पावर;
• और इसी तरह।

संभावना है कि आप केवल इसके बारे में एक छोटे से सबसेट की परवाह करेंगे: जो भी प्रासंगिक है चुनें। एक रेसिंग गेम पहियों के बारे में अधिक जानकारी में जा सकता है, जैसे कि वे कितने गर्म हैं, कितना पहना हुआ है, चौड़ाई और चलने का प्रकार और इसी तरह। ऐसे मामले में, एक व्हील ऑब्जेक्ट को उस राज्य (लेकिन थोड़ा व्यवहार) का संग्रह कहा जा सकता है क्योंकि एक कार में कई पहियों और पहियों का आदान-प्रदान होता है।

तो यह ऑब्जेक्ट्स के बारे में दूसरा बिंदु लाता है: किसी ऑब्जेक्ट के संबंध में एक वस्तु मौजूद हो सकती है जैसे ऑब्जेक्ट डेटा के पूर्ण सेट का प्रतिनिधित्व करता है। तो एक व्हील में चलना, चौड़ाई, तापमान आदि हो सकता है। आप इसे विभाजित नहीं कर सकते हैं और कह सकते हैं कि एक कार चलती है लेकिन कोई पहिया चौड़ाई नहीं है, इसलिए व्हील को ऑब्जेक्ट होने के लिए यह समझ में आता है क्योंकि इसकी पूरी तरह से एक व्हील एक दूसरे के बदले में है।

लेकिन फिर, क्या यह समझ में आता है कि क्या कर रहा है? यह महत्वपूर्ण सवाल है।

Answer 2

चीजों को वर्गीकृत करके शुरू न करें - ऐसा लगता है कि लोग विरासत पदानुक्रमों का निर्माण शुरू करने के लिए उत्सुक हैं।

विशिष्ट, ठोस परिदृश्यों की एक सूची लिखें - आपका ऐप क्या करेगा, चरण-दर-चरण। एक ऑब्जेक्ट मॉडल केवल तभी उपयोगी होता है जब आपको ऐसा करने की ज़रूरत होती है - इसलिए परिदृश्यों से वापस काम करना शुरू करें ताकि यह देखने के लिए कि आप कौन सी सामान्य वस्तुएं और व्यवहार कर सकते हैं।

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

प्रत्येक भूमिका "क्या करता है" कार्य करें। कुंजी में नामांकित भूमिकाओं का एक गुच्छा है - जो वस्तुओं की पहचान करेगा। थिन्स प्रत्येक भूमिका को करने के लिए चीजों का एक सेट डिस्टिल करने के बारे में है - वे पूरी चीज कर सकते हैं, या काम करने के लिए अन्य वस्तुओं का एक समूह डाल सकते हैं, या वे काम समन्वय कर सकते हैं ... यह आपके परिदृश्यों पर निर्भर करता है ।

ओओडी/ओओपी में सबसे महत्वपूर्ण बात - ऑब्जेक्ट्स चीजें हैं - उनके अंदर क्या नहीं है - वे क्या करते हैं।

पर विरासत के बारे में मत सोचो - क्योंकि यह आपको अत्यधिक पदानुक्रमों में जोड़ देगा और आपको ऑब्जेक्ट उन्मुख प्रोग्रामिंग के बजाय एसक्यूएल-उन्मुख प्रोग्रामिंग के मामले में सोचने देगा। विरासत सामान्य कोड साझा करने का एक ही तरीका है। अन्य तरीके के बहुत सारे हैं - प्रतिनिधिमंडल, mixins, प्रोटोटाइप-आधारित प्रोग्रामिंग ...

यहां कुछ दिशानिर्देश मैं के साथ आया था इस के साथ मदद करने के लिए कर रहे हैं:

What should be on a checklist that would help someone develop good OO software?

Answer 3

गुण या चर अक्सर एक भाषा के "आधार" प्रकार होते हैं। सवाल यह है कि आप समझदारी से अमूर्त कर सकते हैं। numberOfTreads, diameter, width, recommendedPressure, brand:

उदाहरण के लिए, आप पूर्णांकों की तरह आधार प्रकार, फ्लोटिंग प्वाइंट मूल्यों और तार से बना वर्णनकर्ता, जो किसी भी पहिया की विशेषता गुण का प्रतिनिधित्व करने के लिए एक Wheel कम कर सकते हैं। Wheel ऑब्जेक्ट बनाने के लिए उन विशेषताओं को मूल प्रकारों के साथ व्यक्त किया जा सकता है।

क्या आप उन गुणों में से कुछ को एक अधिक अमूर्त व्यवस्था में समूहित कर सकते हैं जिसे आप पुन: उपयोग कर सकते हैं, Wheel से स्वतंत्र? मुझे ऐसा लगता है।शायद Dimensions ऑब्जेक्ट्स diameter और width गुणों के साथ बनाएं। फिर आपके Wheel में diameter और width के बजाय Dimensions ऑब्जेक्ट इंस्टेंस इसके साथ जुड़ा हुआ है। लेकिन आप अन्य ऑब्जेक्ट्स के साथ उस Dimensions ऑब्जेक्ट का उपयोग करने के बारे में सोच सकते हैं, जो कि Wheel उदाहरणों के लिए आवश्यक नहीं हो सकता है।

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

सारण Wheel और Dimensions आपको इन ऑब्जेक्ट प्रकारों को विभिन्न संदर्भों में दोबारा उपयोग करने देता है जिन्हें आप प्रारंभ में नहीं मान सकते हैं। यह आपके जीवन को थोड़ा आसान बनाता है क्योंकि सिद्धांत में, आपके पास फिर से लिखने के लिए कम कोड है।

यदि आप ऑब्जेक्ट्स का पदानुक्रम बना सकते हैं, तो उस बिंदु पर जहां गहरा, निम्न-स्तर वस्तु केवल कुछ आधार प्रकारों से बना है, जो शायद शुरू करने के लिए एक अच्छी जगह है।

Answer 4

यदि यह सच है कि "दोनों प्रोग्राम संरचनाएं लक्ष्य को पूरा करती हैं" तो समान रूप से अच्छी तरह से, इससे कोई फर्क नहीं पड़ता कि आप क्या चुनते हैं।

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

Answer 5

मुझे Wirfs-Brock की Responsibility-Driven Design (RDD) पसंद है और यह अद्यतन (फ्री पेपर) Responsibility-Driven Modeling एलिस्टेयर कॉकबर्न द्वारा दृष्टिकोण की भी अनुशंसा करता है।

ओओ विकास के 15 वर्षों में, जब भी मुझे लगा कि मैं एक सॉफ्टवेयर आर्किटेक्चर में खो रहा हूं, तो आरडीडी मूलभूत बातें पर वापस जाने से मुझे हमेशा यह स्पष्ट करने में मदद मिलती है कि सॉफ्टवेयर क्या कर रहा है और कैसे।

यदि आपको परीक्षण-संचालित दृष्टिकोण पसंद है, तो this article दिखाता है कि आरडीडी को वस्तुओं और परीक्षणों का मज़ाक उड़ाते हुए कैसे संबंधित किया जाए।

Answer 6

यहां कुछ अच्छे उत्तर दिए गए हैं, लेकिन संभवतः आप जितना अधिक देख रहे थे उससे अधिक हैं। संक्षेप में अपने विशिष्ट प्रश्नों को संबोधित करने के लिए:

• मुझे कैसे पता चलेगा जब कार एक वस्तु, या एक कार का पहिया एक वस्तु बनाने के लिए, जब दोनों कार्यक्रम संरचनाओं लक्ष्य को पूरा करेंगे?

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

  इस उत्तर को कक्षाओं में थोड़ा बढ़ाकर, जब दो समान वस्तुओं के व्यवहार और/या गुण अलग हो जाते हैं, तो आपको एक नई कक्षा की आवश्यकता होती है।

  तो, यदि आप यातायात सिमुलेशन का मॉडल कर रहे हैं जो पहियों की गणना करता है, तो नंबरऑफहेल्स संपत्ति वाला वाहन वर्ग पर्याप्त हो सकता है। यदि आप विस्तृत सड़क-सतह और व्हील-टोक़ भौतिकी के साथ रेसिंग सिमुलेशन मॉडलिंग कर रहे हैं, तो प्रत्येक पहिया को शायद एक स्वतंत्र वस्तु होने की आवश्यकता है।

• मैं किसी ऑब्जेक्ट के हिस्सों को वर्गीकृत और वर्गीकृत कैसे कर सकता हूं यह निर्धारित करने के लिए कि वे सरल विशेषताओं या किसी ऑब्जेक्ट के चर के रूप में बेहतर हैं या नहीं, या यदि उन्हें वास्तव में ऑब्जेक्ट होने की आवश्यकता है?

  प्रमुख भेद पहचान और व्यवहार हैं। अद्वितीय अस्तित्व वाला एक हिस्सा एक वस्तु है। स्वायत्त व्यवहार के साथ एक हिस्सा अपनी कक्षा की आवश्यकता है।

  उदाहरण के लिए, यदि आप एक बहुत ही सरल कार-क्रैश सिमुलेशन बना रहे हैं, तो नंबरऑफ पैसेंजर और क्षतिपूर्ति एक सामान्य वाहन वर्ग के पर्याप्त गुण हो सकते हैं। यह आपको बताने के लिए पर्याप्त होगा कि कार कुल हो गई थी और यात्री बच गए थे। यदि आपका सिमुलेशन अधिक विस्तृत है, तो शायद आप जानना चाहते हैं कि प्रत्येक यात्री को टकराव पर कितना दूर फेंक दिया गया था, तो आपको प्रत्येक वाहन में एक यात्री वर्ग और अलग यात्री वस्तुओं की आवश्यकता होगी।

Answer 7

अपनी कक्षाओं नीचे से ऊपर की संख्या बढ़ाएं।

1) कक्षा सीमाएं और अर्थशास्त्र संदर्भ पर निर्भर करते हैं। जब तक आपके पास कोई संदर्भ न हो, आपके पास कुछ भी नहीं है। (आपके पास आपके उदाहरण में एक कार भी नहीं हो सकती है)। संदर्भ उपयोगकर्ता की कहानी (या केस का उपयोग) द्वारा दिया जाता है।

2) दिए गए संदर्भ द्वारा दिए गए सभी राज्यों और व्यवहार को एक वर्ग में फेंक दें (यदि आप चाहें तो उपयोगकर्ता की कहानी के बाद इसे नामित कर सकते हैं)।

3) इस वर्ग को अलग-अलग वर्गों में अलग करने के लिए व्यवस्थित Refactoring का उपयोग करें। रिफैक्टरिंग करते समय, मौजूदा वर्गों का पुन: उपयोग अवसरों के रूप में उपयोग करें।

जब आप पूरा कर लेंगे, तो आपके पास अच्छी तरह से परिभाषित कक्षाओं का एक सेट होगा जो कि दी गई उपयोगकर्ता कहानी (और उपयोगकर्ता की कहानियों से पहले की जरूरतों को पूरा करने के लिए पर्याप्त है)।