ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग का अभ्यास कैसे करें? [बन्द है]


13

मैंने हमेशा प्रक्रियात्मक भाषाओं में प्रोग्राम किया है और वर्तमान में मैं ऑब्जेक्ट ओरिएंटेशन की ओर बढ़ रहा हूं। मैंने जो मुख्य समस्या का सामना किया है वह यह है कि मैं एक प्रभावी तरीके से ऑब्जेक्ट ओरिएंटेशन का अभ्यास करने का तरीका नहीं देख सकता। मैं अपनी बात समझाता हूँ। जब मैंने PHP और C सीखा है, तो अभ्यास करना बहुत आसान था: यह केवल उस चीज के लिए एक एल्गोरिथम के बारे में कुछ चुनने और सोचने की बात थी।

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

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

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

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

उसके कारण, वस्तु अभिविन्यास का अभ्यास करने का एक अच्छा तरीका क्या है?


1
मेरे विश्वविद्यालय के शुरुआती वर्षों के दौरान, ब्रूस एकेल द्वारा OOP की एक महान शुरूआत "थिंकिंग इन जावा" पुस्तक थी। यह प्रोग्रामिंग newbies के लिए और प्रक्रियात्मक विकास पृष्ठभूमि से आने वाले लोगों के लिए दोनों की सिफारिश की गई थी - शायद यह आपकी मदद करेगा।
Ivaylo Slavov

3
PHP ऑब्जेक्ट-ओरिएंटेड है; आप अभी इसका उपयोग नहीं कर रहे हैं। php.net/manual/en/language.oop5.php
रॉबर्ट हार्वे

आप ओओपी दृष्टिकोण का उपयोग करके एक ही ऐप को फिर से लागू कर सकते हैं। आखिरकार, यह सिर्फ एक उपकरण है। नीचे से अनुशंसा एक GOF पुस्तक है और एक वस्तु उन्मुख तरीके से अपने मौजूदा प्रक्रियात्मक कोड को फिर से सोचने की कोशिश भी एक अच्छा अभ्यास हो सकता है।
JensG

छोटे गेम (ग्राफिक्स के बिना), कार्ड गेम या शुरुआत में समान करें, उन खेलों में कक्षाओं का पुन: उपयोग करने का प्रयास करें। stackoverflow.com/questions/1301606/…
grizwako

जवाबों:


20

अब, ऑब्जेक्ट ओरिएंटेशन में हमारे पास बहुत सी अतिरिक्त चीजें हैं।

नहीं तुम नहीं ...

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

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग का अभ्यास करने के लिए उन चीजों में से कोई भी आवश्यक नहीं है।

यह बहुत आसान था, यह कुछ उपयोगकर्ता को पंजीकृत करने, उपयोगकर्ता को लॉगिन करने और उत्पादों को जोड़ने के लिए एक एल्गोरिथ्म के बारे में सोचने का विषय था।

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

अंतर केवल इतना है कि आपको जिन कार्यों की आवश्यकता है उन पर ध्यान केंद्रित करने और वे कैसे काम करते हैं, इसके बजाय, आप इस बात पर ध्यान केंद्रित करते हैं कि कार्यक्षमता और स्थिति को जिम्मेदारियों में कैसे बांटा गया है, और उन जिम्मेदारियों को कैसे बातचीत करते हैं।

अभ्यास कैसे करें? उसी तरह से आप प्रक्रियात्मक प्रोग्रामिंग का अभ्यास करते हैं: एक समस्या उठाओ और कक्षाओं के बंडलों का उपयोग करके समस्या को हल करें। पता चला कि कैसे चूसा, सीखा सबक के साथ दोहराएँ।


3
+1 "चित्रा कैसे चूसा कि" यह है कि मैं कैसे कोड: शर्म और आत्म घृणा से भरा ... हमेशा पिछले परियोजनाओं से सीखने के लिए लड़ रहा है।
वर्नरसीडी

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

6

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

मेरी सलाह आपके अभ्यास सत्र को दो बातों को ध्यान में रखकर शुरू होगी: परीक्षण-संचालित विकास और एकल जिम्मेदारी सिद्धांत

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

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

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


1
तो मूल रूप से आप "सीखें टीडीडी और जीओएफ"
रॉबर्ट हार्वे

3

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

यह आपको आईएस-ए और एचएएस-ए संबंधों के बेहतर ज्ञान को विकसित करने में मदद करेगा , जो संभवतः किसी भी ओओपी डिजाइन में सबसे महत्वपूर्ण वर्गीकरण है (और इसके बावजूद, यह अभी भी कुछ ऐसा लगता है जो कई अनुभवी ओओपी भाषा प्रोग्रामर संघर्ष करते हैं। )। यदि आप IS-A / HAS-A में मास्टर हैं, तो IS-IMPLEMENTED-IN-TERMS-OF (जिसे मैंने IS-KIND-OF-A: ^ के रूप में भी देखा है)

गंभीरता से, सुपरमार्केट की अगली यात्रा, बस कल्पना कीजिए कि किसी ने आपको जगह का OOP सिमुलेशन लिखने का काम दिया है ...


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

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

1

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

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


0

चलो कुछ शब्दावली, ऑब्जेक्ट-ओरिएंटेड विश्लेषण और ऑब्जेक्ट-ओरिएंटेड डिज़ाइन जोड़ते हैं , जैसा कि पीटर कोड ने 1990 के दशक में किया था

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

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

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


0

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

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

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