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

Question 1

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

8 साल पहले बंद हुआ ।

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

Question 2

मैं कहूंगा कि OO प्रोग्रामिंग पर कम ध्यान दें और OO डिजाइन पर अधिक ध्यान केंद्रित करें । एक कागज और एक पेंसिल (या शायद एक यूएमएल मॉडलिंग टूल) पकड़ो, और स्क्रीन से दूर हो जाओ।

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

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

बहुत सारे डिज़ाइन अभ्यास के बाद, आप उन सामान्य क्षेत्रों को देखना शुरू करेंगे, जिन्हें संशोधित या सारगर्भित किया जा सकता है, और आपको अपने डिज़ाइन और कोड दोनों में सुधार दिखाई देगा।

Question 3

सबसे आसान तरीका है कि आप SOLID, DRY, FIT, DDD, TDD, MVC, आदि जैसी अवधारणाओं को सीखें। जैसा कि आप इन योगों को देखते हैं, यह आपको कई अन्य खरगोशों के छेदों में ले जाएगा और एक बार आपके पढ़ने के साथ आपके पास होना चाहिए क्या बेहतर वस्तु उन्मुख प्रोग्रामिंग की अच्छी समझ है!

ठोस पॉडकास्ट: http://www.hanselminutes.com/default.aspx?showID=168 , http://www.hanselminutes.com/default.aspx?showID=163

ठोस टूट: http://butunclebob.com/ArticleS.Unclebus.PrinciplesOfOod

DRY: http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

FIT: http://www.netwellness.org/question.cfm/38221.htm

DDD: http://dddcommunity.org/

DDD को पढ़ने की आवश्यकता है: http://www.infoq.com/minibooks/domain-driven-design-quickly

TDD: http://en.wikipedia.org/wiki/Test-driven_development

MVC: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

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

Question 4

बहुत से लोग पहले, वस्तुओं, पिछले कोडिंग के बारे में सोचते हैं।

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

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

Question 5

मेरा सुझाव कुछ अलग सीखना होगा।

कार्यात्मक प्रोग्रामिंग सीखें, और जो आप सीखते हैं उसे ओओपी से लागू करें। यदि आप C ++ जानते हैं, तो जेनेरिक प्रोग्रामिंग के साथ खेलें।

गैर-ऑब्जेक्ट-ओरिएंटेड भाषाएँ सीखें।

सिर्फ इसलिए नहीं कि आपको इन सभी चीजों का उपयोग करना चाहिए (आपको चाहिए), या क्योंकि उन्हें पूरी तरह से ओओपी को प्रतिस्थापित करना चाहिए (वे शायद नहीं करना चाहिए), लेकिन क्योंकि आप इन से ओओपी पर भी सबक ले सकते हैं।

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

नेत्रहीन ओओपी को लागू करने की कोशिश कर रहे हैं, या सबसे अच्छा ओओपी कोड लिखने का प्रयास कर रहे हैं, जिससे कई हद तक अमूर्त और अप्रत्यक्ष और बहुत कम लचीलेपन के कई स्तरों के साथ बड़ी मात्रा में गड़बड़ हो सकती है।

अच्छा OOP कोड लिखने की कोशिश न करें। अच्छा कोड लिखने की कोशिश करें। और OOP का उपयोग करें जब यह उस लक्ष्य में योगदान देता है।

Question 6

कई क्षेत्रों में एक "यूरेका" क्षण है जहां सब कुछ एक साथ आता है।

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

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

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

Question 7

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

Question 8

Aswer आपके प्रश्न में है;)

अभ्यास, अभ्यास, अभ्यास।

अपने स्वयं के कोड की समीक्षा करें और गलतियों से सीखें।

Question 9

टीडीडी ने मुझे ओओपी सहित अपने समग्र कौशल को सुधारने में सबसे अधिक मदद की है।

Question 10

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

... चुपके से मैं अपने सहयोगियों से ईर्ष्या के साथ कुछ चीजें देखता हूं। उनमें से बहुत से कुछ आंतरिक OO वृत्ति है कि मेरे पास नहीं है - कोई फर्क नहीं पड़ता कि मैं कितना मुश्किल कोशिश ...

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

Question 11

भाषा डिजाइनरों ने "ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग" की अलग-अलग तरीकों से व्याख्या की है। उदाहरण के लिए, एलन के, किस व्यक्ति ने पहली बार OOP शब्द का उपयोग किया, इसे परिभाषित किया:

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

(से उद्धरित http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en )।

यह अजीब लग सकता है कि वह जावा और सी ++ ओओपी भाषाओं पर विचार नहीं करता है! लेकिन पहली और सबसे अच्छी OOP भाषाओं में से एक (स्मॉलटाक) के डिजाइनर के रूप में उसके पास इसके अपने वैध कारण हैं। एलन काय ने लिस्प को ऑब्जेक्ट ओरिएंटेड भाषा क्यों माना लेकिन जावा नहीं? यह प्रश्न OOP को समझने का दावा करने वाले किसी भी व्यक्ति द्वारा गंभीर विचार की मांग करता है।

Erlang में OOP, स्कीम की पूरी तरह से अलग-अलग संरचना है एक और है। यह इन सभी वैकल्पिक विचारों पर विचार करने के लायक है। यदि संभव हो तो इन सभी भाषाओं को सीखें! यह आपको एक व्यापक दृष्टिकोण देगा, कुछ नए और शक्तिशाली उपकरण आपके हाथ में देगा और आपको एक बेहतर प्रोग्रामर बना देगा।

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

Question 12

       public void MasteryOfOOP() 
    { 
       while(true)

        /* My suggestion is: */
     DO: find a lot of well-written object oriented code and read it.  Then 
try to use the insights from it on your own coding.  Then do it again.  Then 
have a colleague who is a good OOP look at it and comment. Maybe post a chunk 
of your code on SO and ask for how it could be improved.

        Then read some more of those books.  Maybe they make a little more 
sense now...?

        Now go back to the top of this post, and do it again. 

        Repeat Forever.

        }
    }

Question 13

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

इस प्रकार की प्रत्येक चीज़ जिसे आप ट्रैक करने का निर्णय लेते हैं वह एक वर्ग बन जाती है।

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

सामान्य तौर पर, आपकी कक्षा संरचना में रहने के लिए किसी दिए गए बिट कोड के लिए हमेशा एक सुंदर प्राकृतिक स्थान होना चाहिए। अगर वहाँ नहीं है, तो संकेत है कि वहाँ एक जगह है जहाँ संरचना का निर्माण करने की आवश्यकता है।

Question 14

वस्तुओं के बारे में बहुत अधिक जानकारी है। सबसे महत्वपूर्ण बात यह है कि मूल बातें मास्टर करना और सब कुछ आसानी से जगह में गिर जाता है।

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

यह परम आधारभूत है। तीन और अवधारणाएँ हैं जिनका आपको पूरी तरह से पालन करना चाहिए:

वंशानुक्रम - यह सभी कोड पुन: उपयोग के बारे में है।

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

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

यदि इन अवधारणाओं को बहुत अच्छी तरह से समझा जाता है, तो आप ठीक हो जाएंगे।

एक अंतिम अंतिम टिप: आप सबसे अच्छी पुस्तकों का उल्लेख करते हैं। क्या आपने ब्रूस एकेल द्वारा " थिंकिंग इन जावा " पढ़ा है ? मैं इस पुस्तक को उन लोगों के लिए भी सुझाता हूं जो कि .Net में शुरुआत कर रहे हैं, क्योंकि OOP की अवधारणाएं स्पष्ट रूप से निर्धारित हैं।

Question 15

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

Question 16

ओओपी कौशल समय के साथ आता है। 1, 2 ... 10 किताबें पढ़ना इसे काटता नहीं है। कुछ कोड लिखने का अभ्यास करें। यदि आप एक प्रोग्रामिंग एनवायरनमेंट में काम कर रहे हैं ... जो मददगार हो सकता है। अगर एक में कोशिश नहीं हो रही है। कुछ एप्लिकेशन को मुफ्त में विकसित करने की पेशकश करें। आपको अपने हाथों को गंदा करना होगा। याद रखें ... कोई भी आवेदन जमीन से सही नहीं है। फिर से फैक्टरिंग क्यों होती है।

इसके अलावा ... OOP के साथ बहुत दूर नहीं किया जाता है ... यह समय के साथ बढ़ता है। पूरी तरह कार्यात्मक अनुप्रयोगों के विकास के बारे में चिंता।

Question 17

स्वयं में कुछ प्रोग्रामिंग का प्रयास करें , आसपास की सबसे शुद्ध OO भाषाओं में से एक। इतना शुद्ध, वास्तव में, कि इसमें कक्षाएं भी नहीं हैं, केवल वस्तुएं हैं। इसमें चर, क्षेत्र, स्टेटिक्स, विशेषताएँ, केवल विधियाँ नहीं हैं। यह भी दिलचस्प तथ्य है कि सिस्टम की प्रत्येक वस्तु स्क्रीन पर भी एक वस्तु है और इसके विपरीत।

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

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

Question 18

जब मैंने बैंक-जैसा कार्यक्रम चलाने की कोशिश की, तो लेन-देन, गणना की गई ब्याज, और सब पर नज़र रखने की कोशिश करने के बाद OO ने आखिरकार मेरे लिए क्लिक किया। मैंने यह तब किया जब मैं जावा सीख रहा था। मेरा सुझाव है कि इसे पूरा करने की कोशिश करें, इसे पूरा करें, और फिर जब आप कर लें तो एक अच्छा समाधान देखें और देखें कि आपने क्या बेहतर किया है।

Question 19

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

Question 20

अपनी आस्तीन और कोड रोल करें!

Question 21

आपने स्वयं उत्तर दिया: अभ्यास करें। इसके लिए सबसे अच्छा समाधान एक खेल विकसित करना है। वहां की किताबों में आपके द्वारा सीखी गई अवधारणाओं का उपयोग करें।

Question 22

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

वास्तव में, आप यहाँ पर इसी तरह के एक प्रश्न के लिए मेरा जवाब देखना पसंद कर सकते हैं ।

HTH

चियर्स,

Question 23

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

चीजों को इस तरह से कोड करें कि यदि आप कोड के 1 टुकड़े को बदलना चाहते हैं, तो आपको केवल उस 1 कोड के कोड को बदलना होगा न कि उसके 50 उदाहरणों को।

Question 24

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

सौभाग्य!

Question 25

बीयर मदद करता है। गंभीरता से। ए 3 आकार के स्क्रिबल पैड, एक पेन और बीयर के साथ एक सोफे पर लेट जाएं। कुत्ते, बिल्ली और पत्नी को बाहर से बंद कर दें। और आराम करते समय समस्या के बारे में सोचें। यहां तक कि उस पर एक एपीआई आकर्षित करने की हिम्मत मत करो!

फ़्लोचार्ट्स, रिस्पॉन्सिबिलिटी कार्ड्स (CRC) और बीयर (लेकिन बहुत ज्यादा नहीं) एक लंबा रास्ता तय करते हैं।

रिफैक्टर कोड के लिए सबसे आसान तरीका पहली जगह में नहीं है।

Question 26

http://misko.hevery.com/code-reviewers-guide/

वे छोटे सरल नियम आपको एक बेहतर OO प्रोग्रामर बना देंगे। आप कोड के रूप में नियमों का धार्मिक रूप से पालन करें और आप पाएंगे कि आपका कोड इससे बेहतर है अन्यथा नहीं।

आप ठोस सिद्धांतों को भी सीखना चाहेंगे: http://butunclebob.com/ArticleS.Unclebus.PrinciplesObod

के रूप में इन सिद्धांतों और प्रोग्रामिंग के तरीके बहस का कारण है, वे वास्तव में उत्कृष्ट कोड लिखने का एकमात्र तरीका है।

आप पहले से ही इस तरह से कोड लिख सकते हैं और यह नहीं जानते हैं - यदि हां, तो बढ़िया। लेकिन अगर आपको लक्ष्य के लिए प्रयास करने की आवश्यकता है, तो ये सोने के मानक हैं।

Question 27

छोड़ दो! आपको उस OOP की आवश्यकता क्यों है? बस कुछ प्रयोग करने योग्य ऐप लिखें। OOP, प्रक्रियात्मक या कार्यात्मक दृष्टिकोण का उपयोग करते हुए फ्लॉप मीट्रिक।

जो भी दृष्टिकोण आप पायथन भाषा का चयन करते हैं, उसे अभ्यास करने के लिए संवेदनशील होना चाहिए।

Question 28

आप मेरे लक्षित दर्शक हैं। को देखो OO डिजाइन में बिल्डिंग कौशल

शायद यह मदद कर सकता है।