आप ऑब्जेक्ट ओरिएंटेड प्रोजेक्ट्स को कैसे डिज़ाइन करते हैं? [बन्द है]


231

मैं एक बड़ी परियोजना (मेरे लिए) पर काम कर रहा हूं, जिसमें कई कक्षाएं होंगी और इसे एक्स्टेंसिबल करने की आवश्यकता होगी, लेकिन मुझे यकीन नहीं है कि मेरे कार्यक्रम की योजना कैसे बनाई जाए और कक्षाओं को कैसे बातचीत करना है।

मैंने एक OOD कोर्स लिया और कुछ सेमेस्टर वापस लिए और उससे बहुत कुछ सीखा; यूएमएल लिखना और वस्तुओं और कक्षाओं में आवश्यकताओं के दस्तावेजों का अनुवाद करना। हमने अनुक्रम आरेख भी सीखे, लेकिन किसी तरह मैं व्याख्यान या कुछ याद किया, वे वास्तव में मेरे साथ नहीं थे।

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

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

तो उच्च स्तर के डिजाइन चरण (प्रोग्रामिंग शुरू करने से पहले) के दौरान आप क्या कर रहे हैं, यह निर्धारित करने के लिए कि आपको किन वर्गों की आवश्यकता है (विशेष रूप से किसी 'वास्तविक दुनिया की वस्तुओं पर आधारित नहीं) और वे एक-दूसरे के साथ कैसे बातचीत करेंगे ?

विशेष रूप से मुझे इस बात में दिलचस्पी है कि आपके द्वारा उपयोग किए जाने वाले तरीके क्या हैं? ऐसी कौन सी प्रक्रिया है जिसका आप पालन करते हैं कि आमतौर पर एक अच्छा, साफ डिजाइन होता है जो अंतिम उत्पाद का बारीकी से प्रतिनिधित्व करेगा?


2
मुझे लगा कि इस विषय पर कोड कम्पलीट काफी मददगार था - विशेष रूप से अध्याय ५.३ और ५.४ (जिसमें कुछ और ठोस सुझाव हैं), और पूरे अध्याय ६. हालांकि, मैंने वास्तव में किसी बड़े प्रोजेक्ट के लिए कोई कोड डिज़ाइन नहीं किया है।
पॉल डी। वेट

1
मैं जावा में ऑब्जेक्ट ओरिएंटेड डिज़ाइन पर एक कोर्स लेने की सलाह दे सकता हूँ। UDEMY udemy.com/mastering-object-oriented-design-in-java/… पर एक उत्कृष्ट एक प्रकाशित हुआ है । मुझे लगता है कि निश्चित रूप से आपकी मदद कर सकता है। एटीएम ऑब्जेक्ट ओरिएंटेड समस्या का प्रयास करने के लिए एक और महान संसाधन है। आप इसे google कर सकते हैं।
हॉर्स वॉयस

मैं हर किसी को इस सवाल पर वापस आने की सलाह दूंगा जब आप वास्तव में डिजाइनिंग कर रहे हों। यहां बहुत सारी सामग्री है। इस तरह से आप अपनी याददाश्त को जॉग कर सकते हैं क्योंकि आप वास्तविक डिजाइनिंग कर रहे हैं।
केविन व्हीलर

जवाबों:


199

प्रारंभिक डिजाइन के लिए मेरे द्वारा उपयोग किए जाने वाले चरण (एक वर्ग आरेख के लिए), ये हैं:

  1. ज़रूरत इकट्ठा। क्लाइंट से बात करें और सॉफ्टवेयर को क्या कार्यक्षमता होनी चाहिए, यह परिभाषित करने के लिए उपयोग के मामलों को बताएं।

  2. व्यक्तिगत उपयोग के मामलों की एक कहानी लिखें।

  3. उम्मीदवार वर्गों और क्रियाओं (क्रियाओं), विधियों / व्यवहारों के रूप में कथा और हाइलाइट संज्ञा (व्यक्ति, स्थान, चीज) के माध्यम से जाएं।

  4. डुप्लिकेट संज्ञाओं को छोड़ दें और सामान्य कार्यक्षमता को प्रभावित करें।

  5. एक वर्ग आरेख बनाएँ। यदि आप जावा डेवलपर हैं, तो Sun से NetBeans 6.7 में एक UML मॉड्यूल है जो आरेख के साथ-साथ गोल-यात्रा इंजीनियरिंग के लिए अनुमति देता है और यह मुफ़्त है। एक्लिप्स (एक खुला स्रोत जावा आईडीई), जिसमें एक मॉडलिंग ढांचा भी है, लेकिन मुझे इसके साथ कोई अनुभव नहीं है। तुम भी एक खुला स्रोत उपकरण ArgoUML बाहर की कोशिश करना चाहते हो सकता है।

  6. अपनी कक्षाओं को व्यवस्थित करने के लिए OOD सिद्धांत लागू करें (सामान्य कार्यक्षमता का कारक, पदानुक्रम का निर्माण, आदि)


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

1
मैं जावा में ऑब्जेक्ट ओरिएंटेड डिज़ाइन पर एक कोर्स लेने की सलाह दे सकता हूँ। UDEMY udemy.com/mastering-object-oriented-design-in-java/… पर एक उत्कृष्ट एक प्रकाशित हुआ है। मुझे लगता है कि निश्चित रूप से आपकी मदद कर सकता है। एटीएम ऑब्जेक्ट ओरिएंटेड समस्या का प्रयास करने के लिए एक और महान संसाधन है। आप इसे google कर सकते हैं।
हॉर्स वॉयस

1
आप यह कहां से सीखते हैं? क्या आप कृपया इसका स्रोत प्रदान कर सकते हैं?
कानागवेलु सुगुमार

68

स्कॉट डेवीस को क्या कहना था:

  1. सुनिश्चित करें कि आप जानते हैं कि आपका कार्यक्रम शुरू होने से पहले आपके बारे में क्या है। आपका कार्यक्रम क्या है ? यह क्या नहीं करेगा ? इसे हल करने के लिए क्या समस्या है?

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

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

  4. एक बार जब आपको उपयोग मामलों और वस्तुओं का वह न्यूनतम सेट मिल जाता है, तो कोडिंग शुरू करें। कुछ ऐसा प्राप्त करें जो वास्तव में जितनी जल्दी हो सके चलता है, भले ही यह बहुत कुछ नहीं करता है और शायद बकवास जैसा दिखता है। यह एक शुरुआती बिंदु है, और आपको उन सवालों के जवाब देने के लिए मजबूर करेगा जो आप कागज पर चमक सकते हैं।

  5. अब वापस जाएं और अधिक उपयोग के मामलों को चुनें, लिखें कि वे कैसे काम करेंगे, अपने वर्ग मॉडल को संशोधित करें, और अधिक कोड लिखें। अपने पहले कट की तरह, एक समय में जितना हो सके उतना कम लें और फिर भी कुछ सार्थक जोड़ें। धोये और दोहराएं।

केवल मेरे दो सेंट्स। उम्मीद है कि यह उपयोगी है।


19

जब मेरे पास मौका था, मैं सामान्य रूप से "तीन पुनरावृत्तियों नियम" का उपयोग करता हूं।

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

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

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

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

तो संक्षेप:

  1. पुनरावृति एक में, आपको इसका स्वाद मिलता है, और सीखते हैं
  2. पुनरावृत्ति दो में, आप अपने उत्पाद को साफ करते हैं और इसे भविष्य के लिए तैयार करते हैं
  3. पुनरावृति तीन में, आप नई सुविधाएँ जोड़ते हैं और अधिक सीखते हैं
  4. गोटो २

16

सबसे दिलचस्प स्रोत मुझे इस बारे में पता है कि बर्ट्रेंड मेयर का दूसरा संस्करण पार्ट डी ऑफ़ ऑब्जेक्ट ओरिएंटेड सॉफ्टवेयर कंस्ट्रक्शन है

भाग डी: ऑब्जेक्ट-उन्मुख कार्यप्रणाली: विधि को अच्छी तरह से लागू करना

19: कार्यप्रणाली, 20: डिज़ाइन पैटर्न: मल्टी-पैनल इंटरेक्टिव सिस्टम, 21: इनहेरिटेंस केस स्टडी: इंटरएक्टिव सिस्टम में "पूर्ववत करें", 22: कक्षाएं कैसे लगाएं , 23: क्लास डिजाइन के सिद्धांत, 24: विरासत का अच्छी तरह से उपयोग करना , 25: उपयोगी तकनीक, 26: शैली की भावना, 27: वस्तु-उन्मुख विश्लेषण, 28: सॉफ्टवेयर निर्माण प्रक्रिया, 29: विधि

दिलचस्प है, अध्याय 22. कक्षाओं को कैसे खोजना है यह ऑनलाइन उपलब्ध है।


12

यह बार-बार दोहराया जाता है लेकिन पूरी तरह से सच है - अपना डेटा समझें।

ओओपी के लिए आपकी कक्षाओं को जानकारी के मुख्य टुकड़ों का वर्णन करना चाहिए और वे कैसे बातचीत करते हैं।

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

यह केवल इसका एक विस्तार है: ठीक से जान लें कि आप क्या करने की कोशिश कर रहे हैं।


12
ऑब्जेक्ट व्यवहार डेटा की तुलना में अधिक महत्वपूर्ण है। यह एनकैप्सुलेशन का प्रत्यक्ष परिणाम है: ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग का दिल। डेटा एक्सपोज़र (सी और पास्कल जैसी भाषाओं से) उन प्रणालियों की ओर ले जाता है जिन्हें बनाए रखना (बढ़ाना और डीबग करना) केवल इसलिए मुश्किल होता है क्योंकि आपको कभी नहीं पता होता है कि सिस्टम में अन्य जगह डेटा में क्या बदलाव करता है। OOP डेटा के बारे में नहीं है; ओओपी व्यवहार के बारे में है। यह एक महत्वपूर्ण अंतर है।
डेव जार्विस

यह एक महत्वपूर्ण अंतर है, लेकिन इसका यह अर्थ नहीं है कि डेटा की तुलना में व्यवहार अधिक महत्वपूर्ण है।
जॉनी

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

10

व्यवहार चालित विकास का उपयोग करके देखें। अपनी पुरानी आदतों को तोड़ना कठिन होगा, लेकिन मैंने पाया है कि जब वास्तविक दुनिया में विकास की बात आती है तो बीडीडी वास्तव में आपकी सबसे अच्छी शर्त है।

http://behaviour-driven.org/


1
+1 परीक्षण / व्यवहार / डोमेन संचालित विकास का उपयोग करके आप कक्षाएं बनाते हैं क्योंकि आप जाते हैं ताकि आप समस्याग्रस्त बड़े सामने वाले डिजाइन झरना पद्धति से बचेंगे।
हेल्वर्ड

8

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

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

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

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

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

बहुत ही कम समय में: ओओ और जानकारी को छिपाने के सिद्धांत को ले लो, और इसे दूसरे स्तर तक खींचो!


पुनश्च: डिजाइन करते समय बहुत स्केचिंग करें, यह वास्तविक वास्तुकला की तरह है!

PPS: इस मामले को अलग-अलग कोणों से जानने की कोशिश करें, बॉक्स के बाहर सोचें (हालाँकि बॉक्स जाने का तरीका हो सकता है), साथियों के साथ चर्चा करना इसके लिए बहुत उपयोगी हो सकता है ... और आपके पास लंच के बारे में बात करने के लिए कुछ है।


7

उचित सफलता के साथ मैंने वास्तविक परियोजनाओं में जिस तकनीक का इस्तेमाल किया है, वह ज़िम्मेदारी प्रेरित डिज़ाइन है, जो Wirfs-Brock की पुस्तक से प्रेरित है।

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

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

यह जानना कि कब रोकना निर्णय का विषय है (जो केवल अनुभव के साथ आता है)।


व्हाइटबोर्ड के लिए +1, उत्कृष्ट बात: DI ने व्हाइटबोर्ड के सामने बैठकर 80% समस्याओं का समाधान किया, बस इसे देखते हुए और यह सोचते हुए कि 'सबसे अच्छा क्या होगा?'
usoban

7

डिजाइन पैटर्न्स

रचनात्मक डिजाइन पैटर्न

सिंगलटन - सुनिश्चित करें कि एक वर्ग का केवल एक उदाहरण बनाया गया है और ऑब्जेक्ट को एक वैश्विक पहुंच बिंदु प्रदान करें।

फैक्टरी (फैक्टरी विधि का सरलीकृत संस्करण) - ग्राहक के लिए तात्कालिकता तर्क को उजागर किए बिना वस्तुओं को बनाता है और एक सामान्य इंटरफ़ेस के माध्यम से नव निर्मित वस्तु को संदर्भित करता है।

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

एब्सट्रैक्ट फ़ैक्टरी - संबंधित कक्षाओं के परिवार को स्पष्ट रूप से उनकी कक्षाओं को निर्दिष्ट किए बिना बनाने के लिए इंटरफ़ेस प्रदान करता है।

बिल्डर - एक वस्तु बनाने के लिए एक उदाहरण को परिभाषित करता है, लेकिन उपवर्गों को यह तय करने देता है कि किस वर्ग को तत्काल निर्माण करना है और निर्माण प्रक्रिया पर बेहतर नियंत्रण की अनुमति देता है।

प्रोटोटाइप - एक प्रोटोटाइप उदाहरण का उपयोग करने के लिए वस्तुओं के प्रकार को निर्दिष्ट करें, और इस प्रोटोटाइप को कॉपी करके नई ऑब्जेक्ट बनाएं।

व्यवहार डिजाइन पैटर्न

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

कमांड - एक ऑब्जेक्ट में एक अनुरोध को एनकैप्सुलेट करें, विभिन्न अनुरोधों के साथ क्लाइंट के पैरामीटर को अनुमति देता है और अनुरोधों को एक कतार में सहेजने की अनुमति देता है।

दुभाषिया - एक भाषा को देखते हुए, इसके व्याकरण के लिए एक निरूपक के साथ एक निरूपण को परिभाषित करें जो भाषा में वाक्यों की व्याख्या करने के लिए प्रतिनिधित्व का उपयोग करता है / एक भाषा के लिए एक डोमेन का नक्शा, एक व्याकरण के लिए भाषा और एक व्याकरणिक वस्तु-उन्मुख डिजाइन के लिए व्याकरण।

Iterator - किसी अंतर्निहित वस्तु के तत्वों को क्रमिक रूप से उसके अंतर्निहित प्रतिनिधित्व को उजागर किए बिना एक्सेस करने का एक तरीका प्रदान करता है।

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

पर्यवेक्षक - वस्तुओं के बीच एक-से-कई निर्भरता को परिभाषित करें ताकि जब कोई वस्तु राज्य बदलती है, तो उसके सभी आश्रितों को सूचित और स्वचालित रूप से अद्यतन किया जाए।

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

टेम्पलेट विधि - एक ऑपरेशन में एक एल्गोरिथ्म के कंकाल को परिभाषित करें, उप-वर्ग / टेम्पलेट विधि के लिए कुछ चरणों का विचलन करते हुए, उप-वर्ग को एल्गोरिथ्म की संरचना को बदलने के लिए बिना एल्गोरिथ्म के कुछ चरणों को फिर से परिभाषित करने देता है।

विज़िटर - ऑब्जेक्ट संरचना के तत्वों पर किए जाने वाले ऑपरेशन का प्रतिनिधित्व करता है / विज़िटर आपको उन तत्वों की कक्षाओं को बदले बिना एक नए ऑपरेशन को परिभाषित करने देता है, जिस पर वह संचालित होता है।

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

स्ट्रक्चरल डिजाइन पैटर्न

एडाप्टर - एक वर्ग के इंटरफ़ेस को दूसरे इंटरफ़ेस क्लाइंट में परिवर्तित करें जिसकी अपेक्षा की जाती है। / एडॉप्टर कक्षाओं को एक साथ काम करने देता है, जो असंगत इंटरफेस के कारण अन्यथा नहीं हो सकता है।

ब्रिज - भाग-पूरे पदानुक्रम का प्रतिनिधित्व करने के लिए पेड़ संरचनाओं में वस्तुओं की रचना करें। / समग्र ग्राहकों को व्यक्तिगत वस्तुओं और वस्तुओं की रचनाओं को समान रूप से व्यवहार करने देता है।

कम्पोजिट - भाग-पूरे पदानुक्रम का प्रतिनिधित्व करने के लिए पेड़ संरचनाओं में वस्तुओं की रचना करें। / समग्र ग्राहकों को व्यक्तिगत वस्तुओं और वस्तुओं की रचनाओं को समान रूप से व्यवहार करने देता है।

डेकोरेटर - एक वस्तु के लिए अतिरिक्त जिम्मेदारियों को गतिशील रूप से जोड़ें।

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

मेमेंटो - एन्कैप्सुलेशन का उल्लंघन किए बिना किसी ऑब्जेक्ट की आंतरिक स्थिति को कैप्चर करना और इस प्रकार आवश्यकता होने पर ऑब्जेक्ट को प्रारंभिक अवस्था में पुनर्स्थापित करने के लिए एक साधन प्रदान करना।

प्रॉक्सी - किसी ऑब्जेक्ट के लिए "प्लेसहोल्डर" को इसके संदर्भों को नियंत्रित करने के लिए प्रदान करें।


2
पैटर्न कुछ लोगों के लिए उपयोगी होते हैं। मुझे लगता है कि आवश्यकताओं में पैटर्न को देखने के लिए काफी अनुभव की आवश्यकता है। और आपको शायद उन्हें दस्तावेज करने की आवश्यकता है। मुझे लगता है कि पैटर्न अमूर्त घटक पुस्तकालयों से ज्यादा कुछ नहीं कर रहे हैं करने के लिए इच्छुक हूँ।
साइबरफोनिक

5

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

से विकिपीडिया :

वैकल्पिक शब्द

BlueJ जावा प्रोग्रामिंग लैंग्वेज के लिए एक इंटीग्रेटेड डेवलपमेंट एनवायरनमेंट है, जिसे मुख्य रूप से शैक्षिक उद्देश्यों के लिए विकसित किया गया है, लेकिन यह छोटे स्तर के सॉफ्टवेयर डेवलपमेंट के लिए भी उपयुक्त है।

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

alt text http://www.ryanknu.com/ryan/bluej.png

ActiveWriter संस्थाओं और संबंधों को मॉडल करने के लिए एक उपकरण है, यह कोड भी बनाता है और परिवर्तन करना आसान है। यह आपको समय की बचत करेगा और चुस्त विकास के लिए बहुत उपयुक्त है।

वैकल्पिक शब्द
(स्रोत: altinoren.com )


1
मैंने ब्लू जे का उपयोग किया है ... यह निश्चित रूप से उपयोगी है लेकिन यह मुझे कक्षाओं और उनके संबंधों को डिजाइन करने में कैसे मदद करता है?
विक्टर

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

4

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

दूसरी बात - OOP और उन कक्षाओं का उपयोग करें जहां एक प्राकृतिक वस्तु पदानुक्रम मौजूद है। कृत्रिम रूप से इसे 'पेंच-इन' न करें। यदि कोई सख्त पदानुक्रम मौजूद नहीं है (जैसे अधिकांश व्यावसायिक अनुप्रयोगों में) - प्रक्रियात्मक / कार्यात्मक के लिए जाएं, या, कम से कम वस्तुओं का उपयोग केवल अलग-अलग एक्सेसरों वाले डेटा कंटेनरों के रूप में करें।

और आखिरी - इसे पढ़ने की कोशिश करें: द एल्गोरिथम ऑफ़ क्रिएटिव थिंकिंग


4

बस http://www.fysh.org/~katie/computing/methodologies.txt के हवाले से

और आरयूपी के मूल में एक छोटा सा क्षेत्र है जहां आपको ओओ डिजाइन प्रतिभाओं का उपयोग करना है .... यदि आपके पास नहीं है, तो यह 100 मीटर चलाने के लिए एक पद्धति है।

"चरण 1: वास्तव में तेजी से चलने के बारे में लिखें। चरण 2: जाओ और रेसट्रैक की एक योजना बनाएं। चरण 3: जाओ और वास्तव में तंग लाइक्रा शॉर्ट्स खरीदें। चरण 4: वास्तव में, वास्तव में, वास्तव में तेजी से दौड़ें। चरण 5: क्रॉस लाइन पहले। "

यह चरण 4 कठिन है। लेकिन अगर आप 1,2,3 और 5 पर बहुत जोर देते हैं, तो यह संभव है कि कोई भी नोटिस नहीं करेगा और फिर आप शायद बहुत पैसा कमा सकते हैं पद्धति को बेचने वाले एथलीट होंगे जो सोचते हैं कि 100 मीटर होने के लिए कुछ "गुप्त" है। दौड़ने वाला


4

आपने प्रश्न पूछा कि बहुत सारे लेखक पुस्तक लिखने के लिए उपयोग करते हैं। कार्यप्रणाली की संख्या है और आपको उस एक को चुनना चाहिए जो आपको "सबसे सुंदर" लगता है।
मैं एरिक इवांस द्वारा बुक "डोमेन ड्रिवेन डिज़ाइन" की सिफारिश कर सकता हूं । इसके अलावा, साइट dddcommunity.org देखें


3

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

यदि आपके पास सिर्फ एक या दो साल का कार्य अनुभव है, तो आपको उस बिंदु पर जाना चाहिए: आप उस बिंदु पर कैसे पहुंचते हैं जो आप वास्तव में अपना डेटा जानते हैं और ठीक से समझते हैं कि आप क्या करने की कोशिश कर रहे हैं?

हाँ, यदि आप वास्तविक दुनिया में 5+ वर्ष से काम कर रहे हैं तो आप कई सॉफ्टवेयर विकास प्रक्रियाओं के मॉडल या तकनीकों में से किसी एक को चुनेंगे।

लेकिन आपको केवल किताबें पढ़ने से अनुभव नहीं मिलता है। आपको एक अच्छे नेतृत्व में एक अच्छे समूह में काम करके सीखना चाहिए।

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

आप अपने कोडबेस के बारे में बहुत कुछ जानेंगे। उपकरण उपकरण हैं, वे आपको कुछ भी नहीं सिखाएंगे।


3

यदि आपके पास उस परियोजना पर डोमेन विशेषज्ञता है जो आप कहते हैं कि बैंकिंग जैसे काम करने जा रहे हैं। अपनी वस्तुओं को संरचना करना आसान है और आप जानते हैं कि हर दूसरे दिन वे एन्हांसमेंट कैसे आते हैं।

यदि आपके पास वह विशेषज्ञता नहीं है, जिसके पास वह विशेषज्ञता है और उन विचारों को तकनीकी विवरण में परिवर्तित करें।

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


2
  1. अध्ययन और मास्टर डिजाइन पैटर्न।
  2. इसके बाद, डोमेन ड्रिवेन डिज़ाइन के बारे में जानें
  3. उसके बाद, आवश्यकता को इकट्ठा करना सीखें

मैंने एक OOD कोर्स लिया और कुछ सेमेस्टर वापस लिए और उससे बहुत कुछ सीखा; यूएमएल लिखना और वस्तुओं और कक्षाओं में आवश्यकताओं के दस्तावेजों का अनुवाद करना। हमने अनुक्रम आरेख भी सीखे, लेकिन किसी तरह मैं व्याख्यान या कुछ याद किया, वे वास्तव में मेरे साथ नहीं थे।

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

  2. उपयोग के मामलों को लिखें, विशेष रूप से वैकल्पिक पाठ्यक्रम के लिए। वैकल्पिक पाठ्यक्रम हमारे विकास के समय के 50% से अधिक पर कब्जा कर लेता है। आम तौर पर जब आपका पीएम आपको कोई काम सौंपता है, उदाहरण के लिए, एक लॉगिन सिस्टम बनाएं, तो उसे लगेगा कि यह सीधे आगे है, इसे खत्म करने में आपको 1 दिन लग सकता है। लेकिन वह कभी भी इस बात पर ध्यान नहीं देता है कि आपको क्या विचार करने की आवश्यकता है, 1. क्या होगा यदि उपयोगकर्ता गलत पासवर्ड, 2. क्या होगा यदि उपयोगकर्ता 3 बार के लिए गलत पासवर्ड में, 3. क्या होगा यदि उपयोगकर्ता उपयोगकर्ता नाम और आदि में टाइप नहीं करता है। आपको उन्हें सूचीबद्ध करने की आवश्यकता है, और इसे अपने पीएम को दिखाएं, उसे समय सीमा को फिर से निर्धारित करने के लिए कहें।


2

मुझे डर है कि यह कोई जवाब नहीं है जिसे लोग सुनना पसंद करते हैं । वैसे भी, मुझे अपनी राय बताने दें।

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

मुझे लगता है कि, ज्यादातर समय OOP और OOD सॉफ्टवेयर बनाते हैं जो ओवर डिजाइन के शिकार होते हैं।

संक्षेप में, सॉफ्टवेयर लिखने का मेरा पसंदीदा तरीका है:

  1. एक गतिशील भाषा का प्रयोग करें।
  2. उस भाषा में ही डिजाइन (प्रोटोटाइप) लिखें।
  3. यदि आवश्यक हो, तो कुछ क्षेत्रों को C / C ++ का उपयोग करके अनुकूलित करें।
  4. कार्यान्वयन भाषा के दुभाषिया के माध्यम से ही व्यापकता प्रदान करें।

अंतिम विशेषता सॉफ्टवेयर को आसानी से विशिष्ट उपयोगकर्ता (स्वयं सहित) की आवश्यकताओं के अनुकूल बनाने में सक्षम बनाती है।


यह शायद ही सलाह है कि कैसे डिजाइन किया जाए
NomeN

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

2

मैं टेस्ट-ड्रिवेन डिज़ाइन (TDD) का उपयोग करता हूँ। पहले परीक्षण लिखना वास्तव में आपको एक ऐसे डिज़ाइन की ओर ले जाने में मदद करता है जो साफ और सही है। Http://en.wikipedia.org/wiki/Test-driven_development देखें ।


2
TDD शुरू में आपके सिस्टम को उसके इनपुट इनपुट और आउटपुट के साथ एक ब्लैक बॉक्स के रूप में कल्पना करने में मदद करता है। लेकिन प्रति se यह आपको सिस्टम के डिज़ाइन के साथ आने में मदद नहीं करता है। मेरा मतलब था कि यूनिट टेस्ट के लिए आपको सबसे पहले क्लास इंटरफेस के साथ आना होगा
विसेंटा बोलिया

2

डिज़ाइन पैटर्न सीखें । ओओपी के बारे में पिछले दो वर्षों में यह मेरी व्यक्तिगत क्रांति रही है। एक पुस्तक प्राप्त करें। मैं आपको इसकी सलाह दूंगा:

हेड फ़र्स्ट डिज़ाइन पैटर्न

यह जावा में है, लेकिन यह किसी भी भाषा के लिए एक्स्टेंसिबल हो सकता है।


1

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


1
जब मैं किसी मुद्दे पर फंस जाता हूं तो मुझे फ्लोचार्ट पसंद होता है। यह कभी-कभी मुझे एक अलग तरीके से समस्या के बारे में सोचने में मदद करता है।
user133018

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

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

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


1

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

वास्तव में। निरीक्षण करें कि साइड फार्मेसी कैसे संचालित होगी, या डॉक्टर के कमरे में।

अपनी डोमेन समस्या को कुछ समझ में आने के लिए नीचे लाएँ; कुछ है जिससे आप संबंधित कर सकते हैं।

फिर एक बार डोमेन के भीतर "खिलाड़ी" स्पष्ट दिखाई देने लगते हैं, और आप अपना कोड मॉडल करना शुरू करते हैं, एक "प्रदाता-उपभोक्ता" मॉडलिंग दृष्टिकोण चुनते हैं, अर्थात आपका कोड मॉडल का "प्रदाता" है, और आप "उपभोक्ता" हैं "।

डोमेन से संबंधित और इसे उच्च स्तर पर समझना किसी भी डिजाइन का प्रमुख हिस्सा है।


1

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.