कोड करने से पहले OOP सिस्टम को डिजाइन करने के लिए एक सरल प्रक्रिया क्या है?

Question

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

एक बार जब हम कक्षाओं और वस्तुओं की अवधारणा को डिजाइन प्रक्रिया में पेश करते हैं, तो हम अब टॉप-डाउन डिज़ाइन नहीं कर सकते हैं, क्योंकि हम अब अपनी समस्याओं को उन चीजों में नहीं तोड़ रहे हैं जिन्हें प्रक्रियाओं के रूप में लागू किया जा सकता है। इसके बजाय, मैंने इस विषय पर जो कुछ पढ़ा है, उसके अनुसार, हमें यह निर्धारित करना चाहिए कि कक्षाओं की क्या आवश्यकता है, और यूनिफाइड मॉडलिंग भाषा में विभिन्न कलाकृतियों का निर्माण करें, जिसका उपयोग हम तब करते हैं जब हम सॉफ्टवेयर को लागू करते हैं। लेकिन इस तरह की डिजाइन प्रक्रिया मुझे समझ में नहीं आती है। कैसे के लिए कोई जानता है कि उन्हें किन वर्गों की आवश्यकता होगी, और वे कैसे बातचीत करेंगे, जब तक कि वे पहले से ही पूरी प्रणाली की कल्पना नहीं करते हैं?

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

Comments

"अब मुझे पता है कि यह सॉफ्टवेयर बनाने का उचित तरीका नहीं है" - यह आपको किसने बताया? ऐसा लगता है कि किसी तरह आप विश्वास करने के लोकप्रिय जाल में पड़ गए हैं "डिजाइन कुछ ऐसा है जो आप कोडिंग से पहले करते हैं, शायद फैंसी यूएमएल आरेख द्वारा"। इस गलत धारणा से आपको ठीक करने के लिए, मैं जैक रीव्स द्वारा "कोड विथ डिज़ाइन" के साथ शुरुआत करने की सलाह देता हूं ।

— डॉक्टर ब्राउन

संभव के नकली ऊपर या नीचे ऊपर डिजाइन करने के लिए बेहतर है?

— डॉक ब्राउन

@DocBrown। क्या आपको नहीं लगता कि कोडिंग करते समय वह डिज़ाइन हमारे काम को इतना कारीगर बनाता है? मैं समान रूप से काम करने वाले अन्य इंजीनियरों की कल्पना नहीं कर सकता। एक ईंट की ईंटों और मोर्टार की कल्पना कीजिए और रास्ते में इमारत / पुल को डिजाइन करें।

— Laiv

@ लिव: "कोडिंग" अन्य इंजीनियर विषयों में क्या है इसका एक हिस्सा है जिसे डिजाइन कहा जाता है। घर की इमारत में, डिजाइन से लेकर अंतिम उत्पाद तक का उपयोग पिलिंग ईंटों और मोर्टार का उपयोग करके किया जाता है। प्रोग्रामिंग में, यह कदम डिज़ाइन (= प्रोग्राम) को अंतिम उत्पाद (= निष्पादन योग्य बाइनरी) में अनुवाद करते समय कंपाइलर द्वारा किया जाता है। और वह कोई नया ज्ञान नहीं है। रीव्स निबंध 25 साल पुराने हैं।

— डॉक्टर ब्राउन

@DocBrown, डेवलपर है। * अब क्यूरेट नहीं किया गया है? उदाहरण के लिए सदस्यता बटन टूट गया है।

— रडारबॉब

Answer 1

ऊपर नीचे झरना शैली OOAD यह सुनिश्चित नहीं करती है कि आप जो कोड लिखते हैं वह ऑब्जेक्ट ओरिएंटेड है। मैंने OOAD के कड़ाई से उत्पादित कोड के पहाड़ों को देखा है जो इसे साबित करता है। यदि OO आपको भ्रमित कर रहा है, तो मदद के लिए यहाँ मत देखो। आप इसे ढूंढ नहीं पाएंगे। OO को आपको टॉप डाउन डिज़ाइन करने की आवश्यकता नहीं है।

यदि एक वर्ग में गोताखोरी करना है कि आप कोड कैसे पसंद करते हैं, तो यह हो। मैं आपको एक संकेत बताता हूं। Procrastinate।

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

इस तरह लिखना सीखें और आप पाएंगे कि आप बहुत मेहनत किए बिना भी OO कर रहे हैं। यह आपको अपनी वस्तुओं को देखने के दृष्टिकोण से मजबूर करता है कि उनका उपयोग कैसे किया जाता है (उनका इंटरफ़ेस) और किन वस्तुओं के बारे में पता है। लगता है कि एक यूएमएल आरेख मुख्य दो बिंदु क्या हैं?

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

Comments

या आप अपने आप को OO नहीं कर पा रहे हैं और फिर भी सब कुछ "किसी भी तरह" ठीक काम करता है ...

— डेरेक एल्किंस ने SE

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

— पियोवेज़न

यह बस ऊपर नीचे नहीं है। आपको उन चीजों का निर्माण नहीं करने के लिए भी तैयार रहना होगा जिन्हें आप मापदंडों को स्वीकार करके पूछ सकते हैं।

— कैंडिड_ऑरेंज

@Piovezan आप यह तब भी कर सकते हैं जब इंटरफ़ेस अभी तक मौजूद नहीं है। बस अपने कंपाइलर को थोड़ा अनदेखा करें। बाद में, आप इसे मौजूद करेंगे।

— कैंडिड_ऑरेंज

@CandiedOrange "आपको उन चीजों का निर्माण नहीं करने के लिए तैयार रहना होगा जो आप केवल मापदंडों को स्वीकार करके पूछ सकते हैं।" - मुझे यकीन नहीं है कि मैं समझ सकता हूं, क्या आप कृपया एक छोटा उदाहरण (या उस मामले के लिए काउंटर-उदाहरण) को स्पष्ट कर सकते हैं / प्रदान कर सकते हैं?

— पियोवेज़न

Answer 2

आप अपने कोड में ऑब्जेक्ट-ओरिएंटेड तकनीकों का उपयोग करने में सक्षम होने का दावा करते हैं, इसलिए इसके द्वारा आप यह जानते हैं कि ऑब्जेक्ट-ओरिएंटेड सिस्टम को पहले से ही कैसे डिज़ाइन किया जाए , मेरा मानना ​​है कि आपकी समस्या तब अधिक होती है , जब आप कर सकते हैं या नहीं। आप दीर्घकालिक योजना के बजाय अल्पकालिक पुनरावृत्त तरीके से ऑब्जेक्ट-उन्मुख डिज़ाइन के साथ सहज महसूस करते हैं।

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

आप दावा करते हैं कि "प्रारंभिक योजना" के बिना-ऑन-फ्लाई विकसित करना है:

"... सॉफ्टवेयर बनाने का उचित तरीका नहीं ..."

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

यदि आपकी समस्या यह है कि आप अपने दस्तावेज़ / डिज़ाइन / यूएमएल कौशल में विश्वास नहीं कर रहे हैं , तो एक मौजूदा परियोजना का दस्तावेजीकरण करके अभ्यास करें।

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

Comments

मैं भी उल्लेख करना चाहता था, हालांकि उत्तर के लिए थोड़ा सा विषय ... आपकी योजनाओं को बहुत बड़ा होने की आवश्यकता नहीं है! कभी-कभी एक योजना सिर्फ "मैं इसे चलाना चाहता हूं और यह एक काम करता है।" यह काफी अच्छा है, अगर यह वास्तव में यह सब करने जा रहा है।

— एरड्रिक आयरन्रोस

Answer 3

OOAD एक यूटोपिया है। इसके द्वारा मेरा मतलब यह नहीं है कि यह सबसे अच्छा तरीका है, मेरा मतलब है कि यह मेरी विनम्र राय में वास्तव में प्राप्त करने योग्य नहीं है। मेरे अनुभव में, कुछ हमेशा बदलता रहता है, चाहे वह आवश्यकताओं या बारीकियों, या यहां तक ​​कि एक निर्भरता संघर्ष हो जो आपको पूरी तरह से एक निर्भरता को बदलने के लिए मजबूर करता है। चाहे ऐसा इसलिए हो क्योंकि मैंने इस तरह सीखा या क्योंकि यह स्वाभाविक रूप से मेरे लिए सबसे अधिक आता है, डिजाइन के लिए मेरे विचार सबसे आसानी से आते हैं क्योंकि मैं कोड लिख रहा हूं। अगर मैं कोड के बारे में हूं और मुझे इस बारे में स्पष्ट जानकारी नहीं है कि मैं कोड को कैसे बनाऊंगा, तो मैं समस्या को पहले समझने के लिए समय समर्पित करने का एक बिंदु बनाऊंगा, हालांकि अधिक बार नहीं, मैं देखता हूं एक कक्षा के लिए आवश्यकता है और मैं इसे बनाऊंगा।

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

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

आपको निम्न में से किसी भी प्रश्न के उत्तर में कक्षा का उपयोग करने पर विचार करना चाहिए:

• क्या मेरे पास सूचना का एक समूह है जो एक ही अवधारणा से संबंधित है (जैसे पहला नाम, अंतिम नाम, पता)?
• क्या मुझे जानकारी के कई टुकड़ों (यानी calculatePrice(basePrice, quantity, tax)) के लिए एक ऑपरेशन करने की आवश्यकता है ?
• क्या मेरे पास एक और है यदि बड़े कोड ब्लॉक समान या समान जानकारी के साथ थोड़ा अलग संचालन करते हैं (यानी if(type == "cat") { meow(name); } else if (type == "dog") { bark(name); }==> animal.speak())
• क्या मेरे पास एक मौजूदा वर्ग है जो एक से अधिक विशिष्ट कार्य करता है और थोड़ा बहुत बड़ा हो रहा है?

थोड़ी देर बाद, यह कक्षाएं बनाने के लिए दूसरा स्वभाव बन जाएगा। यदि आपका कोड ऊपर के किसी मामले में आता है तो उनका इस्तेमाल करने से न डरें। मुझे आशा है कि वह मदद करेंगे!

Answer 4

मुझे लगता है कि टिप्पणियों में डॉक्टर ब्राउन द्वारा किए गए बिंदु एक टिप्पणी की तुलना में बहुत अधिक दृश्यता के लायक हैं क्योंकि वह बिल्कुल सही है:

" अब मुझे पता है कि यह सॉफ्टवेयर बनाने का उचित तरीका नहीं है " - यह आपको किसने बताया? ऐसा लगता है कि किसी तरह आप विश्वास करने के लोकप्रिय जाल में पड़ गए हैं "डिजाइन कुछ ऐसा है जो आप कोडिंग से पहले करते हैं, शायद फैंसी यूएमएल आरेख द्वारा"। इस गलत धारणा से आपको ठीक करने के लिए, मैं जैक रीव्स द्वारा "कोड विथ डिज़ाइन" के साथ शुरुआत करने की सलाह देता हूं । - डॉक्टर ब्राउन 21 जून को 5:27 पर

@ लिव: "कोडिंग" अन्य इंजीनियर विषयों में क्या है का एक हिस्सा है जिसे डिजाइन कहा जाता है। घर के निर्माण में, डिजाइन से लेकर अंतिम उत्पाद तक का उपयोग पिलिंग ईंटों और मोर्टार का उपयोग करके किया जाता है। प्रोग्रामिंग में, यह कदम डिज़ाइन (= प्रोग्राम) को अंतिम उत्पाद (= निष्पादन योग्य बाइनरी) में अनुवाद करते समय कंपाइलर द्वारा किया जाता है। और वह कोई नया ज्ञान नहीं है। रीव्स निबंध 25 साल पुराने हैं। - डॉक्टर ब्राउन जून 21 को 6:39 पर

यही भावना अन्य स्थानों में भी गूँजती है। "रियल सॉफ्टवेयर इंजीनियरिंग" पर ग्लेन वेंडरबर्ग की वार्ता पर विचार करें , और कुछ हद तक उनकी "क्राफ्ट, इंजीनियरिंग, और सार की प्रोग्रामिंग" और "क्राफ्ट और सॉफ्टवेयर इंजीनियरिंग" वार्ता। भी विचार WhatIsSoftwareDesign और TheSourceCodeIsTheDesign पृष्ठों / सी 2 विकि पर विचार विमर्श।

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

एक जटिल प्रणाली में, कुछ लेवल अप आर्किटेक्चरल डिज़ाइन होने की संभावना है - सबसिस्टम, घटकों, मॉड्यूल, सेवाओं की पहचान करना और कोड लिखना शुरू करने से पहले उन्हें आवश्यकताओं को आवंटित करना। आप UML का उपयोग इस वास्तुशिल्प डिज़ाइन के बारे में चर्चा करने, दस्तावेज़ बनाने और सहायता करने के तरीके के रूप में कर सकते हैं। यूएमएल मोड्स के विचार पर विचार करें कि मार्टिन फाउलर चर्चा करते हैं , विशेष रूप से यूएमएल स्केच के रूप में और यूएमएल नोट्स के रूप में । एजाइल मॉडलिंग - इनिशियल आर्किटेक्चर मॉडलिंग , इटरनेशन मॉडलिंग और जस्ट बरेली गुड इनफ मॉडल से कुछ विचारों पर विचार करें ।

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

Answer 5

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

OOAD सिस्टम में बड़े मॉड्यूल के रूप में सोच की सकारात्मकता को बाहर नहीं करता है। आप अभी भी ऐसा कर सकते हैं। प्रत्येक मॉड्यूल उपयोगकर्ता कहानियों (उपयोग मामलों) के एक सेट को संतुष्ट करने के लिए मौजूद है। ऐसी उपयोगकर्ता कहानियों को उन कक्षाओं की आवश्यकता होती है जो उन्हें पूरा करने के लिए सहयोग करते हैं।

प्रक्रियात्मक OO दृष्टिकोणों के बीच एक महत्वपूर्ण अंतर यह है कि आमतौर पर प्रक्रियात्मक सोच स्क्रीन के लिए मानचित्र की आवश्यकताओं को पूरा करती है, जबकि OOD में यह सोचने की प्रवृत्ति होती है कि हुड के नीचे क्या होता है जो किसी अन्य व्यक्ति द्वारा या किसी गैर-ओओ फैशन में बनाए जाने वाले सामने के छोर को छोड़ देता है।

चरम प्रोग्रामिंग में एक तकनीक है जिसे सीआरसी कार्ड कहा जाता है । CRC का अर्थ "वर्ग-जिम्मेदारियों-सहयोगी" है।

मूल रूप से आप स्पष्ट वर्गों की पहचान करते हैं और प्रत्येक को एक कार्ड सौंपते हैं। बोले, क्लास Invoiceका अपना कार्ड होता है।

प्रत्येक कार्ड-धारण वर्ग के लिए आप लिखते हैं कि उस वर्ग की जिम्मेदारियां क्या होंगी, उदाहरण के लिए "एक भव्य कुल की गणना" ।

प्रत्येक कार्ड-धारक वर्ग के लिए, आप लिखते हैं कि उस वर्ग को अपनी जिम्मेदारियों को पूरा करने के लिए किस वर्ग से कुछ पूछना है। यहां आपको खोज की Invoiceआवश्यकता हो सकती है InvoiceDetailया यह भी पता चल सकता है कि पहली जगह में ऐसी कक्षा की आवश्यकता है।

आपको पता चल सकता है कि आपके द्वारा ली गई कुछ जिम्मेदारियां Invoce, वास्तव में उसके सहयोगियों में से एक की हैं।

अभ्यास के बाद, प्रत्येक कार्ड एक वर्ग बन जाता है, प्रत्येक जिम्मेदारी एक विधि बन जाती है और हर सहयोग संबंध एक रचना, एक एकत्रीकरण या मात्र कॉल बन सकता है।

यह एक्सर्साइज़ एक समूह में किया जा सकता है (और होना चाहिए), जहां कारोबारी लोग भी पार्टिकुलेट करते हैं।

आप इन लिंक्स में इस तकनीक के बारे में अधिक जान सकते हैं:

http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card

http://www.extremeprogramming.org/rules/crccards.html

सीआरसी कार्ड के उदाहरण:

Answer 6

सॉफ्टवेयर चिकित्सकों के एक समुदाय के रूप में, हमारे लिए प्राथमिक चुनौती; अधिक विशेष रूप से ऑब्जेक्ट ओरिएंटेड डिज़ाइन प्रैक्टिशनर, हमारी सभी समस्याओं / कार्यों को एक प्रोग्रामिंग कप्टर में कैटेगराइज करने के लिए है। यह हो कार्य - के रूप में प्रतिनिधित्व कार्यों या यह हो अभिनेताओं के रूप में प्रतिनिधित्व - कार्यों के इंटरफेस / वर्गों [OOAD की ओर ड्राइविंग]। जैसा कि हम विभिन्न कार्यप्रणाली / रूपरेखाओं के बारे में लगातार ज्ञान प्राप्त करके अपने सॉफ्टवेयर डिजाइनिंग आदतों को विकसित करते हैं। हमारा दृष्टिकोण स्पष्ट रूप से वस्तुओं को अलग करने की दिशा में अधिक से अधिक परिष्कृत हो जाता है और कौन सी वस्तु किस फ़ंक्शन का प्रदर्शन करेगी।

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

मैं ऑटोमोबाइल की श्रेणी के उदाहरण की मदद से फ़्यूचर को समझाने की कोशिश करूंगा और मैं एक ही ऑब्जेक्ट मॉडल की कल्पना करने के दो अलग-अलग तरीकों को उजागर करूंगा।

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

निर्माता के लिए स्पष्ट रूप से श्रेणी और उद्देश्य का अलगाव होता है, ऐसे कई तरीके हैं जिनसे वे वहां कक्षाएं बना सकते हैं।

1. वाहन की श्रेणी (बाजार क्षेत्र) के आधार पर: भारी वाहन, उपभोक्ता वाहन [सेडान, हैचबैक, स्टेशन-वैगन आदि।

2. इंजन की क्षमता और ड्राइविंग तरीके के आधार पर: 800-1500 CC,> 1500 CC आदि।

सबसे अच्छा तरीका है, जिसमें निर्माता व्यक्तिगत रूप से प्रदान कर सकते हैं द्वारा जा रहे कार्यों ये वर्गीकरण से प्रत्येक से संबंधित वस्तुओं के लिए, वे एक उचित अंतर्निहित वस्तु डिजाइन चुन सकते हैं और यह की चोटी पर वहाँ मॉडल बना सकते हैं।

Comments

आप ठीक करना शुरू करते हैं, लेकिन फिर आखिरी बिट यह गिरावट की तरह दिखता है कि OOD समान व्यवहारों को समूहीकृत करने के बजाय चीजों को वर्गीकृत करने के बारे में है।

— पीट किरखम