ऑब्जेक्ट ओरिएंटेड स्किल्स कैसे बनाएं?

Question

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

उदाहरण के लिए, मुझे एक मुद्रा परिवर्तक डिजाइन करने में कठिन समय था।

अतः मेरे सवाल:

• यह अनुभव से है डिजाइन कौशल प्राप्त किया जा सकता?
• इंटरनेट आदि पर किताबें/ब्लॉग/सामग्री सीखना सीखेंगे?
• क्या यह लागू होने वाले एप्लिकेशन के ज्ञान की आवश्यकता है?
• डिजाइन पैटर्न, सिद्धांतों को जानना?
• 'कोड पूर्ण' पुस्तक का अध्ययन?
• समस्या हल करने के कौशल की आवश्यकता है?

संक्षेप में, एक समस्या दी गई, मैं बस इसे ऑब्जेक्ट उन्मुख तरीके से हल करना चाहता हूं ??

Answer 1

अपने अंकों की संख्या के लिए - मुझे लगता है कि 2 - 6 बहुत अच्छे हैं और मुझे लगता है कि कोड लिखने वाले किसी भी व्यक्ति को कोड को पूरा करना चाहिए, भले ही यह ओओ न हो। लेकिन दुर्भाग्यवश ऐसा लगता है कि बिंदु 1 सबसे महत्वपूर्ण है !!!

मुझे लगता है कि यह हमारे पेशे में एक समस्या है। हम महान कोड का अध्ययन करने के विरोध में नौकरी पर सीखते हैं। इसलिए अनिवार्य रूप से हर कोई सीखने के मामले में पहिया का पुन: आविष्कार कर रहा है।

Answer 2

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

हालांकि, बेहतर ऑब्जेक्ट-उन्मुख डिजाइनर होने के लिए कोई चांदी की बुलेट नहीं है। सबसे अच्छा तरीका, मेरी राय में, एक जटिल कार्यक्रम लिखना होगा, फिर इसे कुछ सालों तक दृढ़ता से बनाए रखें।

Answer 3

• क्या यह अनुभव करके डिज़ाइन कौशल हासिल किया जा सकता है?

अनुभव और सहज क्षमता - कुछ लोग बस ऐसा नहीं कर सकते हैं।

• इंटरनेट पर किताबें/ब्लॉग/सामग्री सीखना आदि मदद करेगा?

बेशक। लेकिन वे आपको ओओ भगवान में नहीं बदलेंगे।

• क्या यह किसी को विकसित किए जा रहे एप्लिकेशन के डोमेन ज्ञान की आवश्यकता है?

या तो आपको इसे प्राप्त करने की आवश्यकता है, या आपको किसी ऐसे व्यक्ति तक पहुंच की आवश्यकता है जो आपको करता है।

• डिजाइन पैटर्न, सिद्धांतों को जानना?

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

• 'कोड पूर्ण' पुस्तक का अध्ययन?

मैंने इसे एक बार बुकशाला में फिसल दिया।

• समस्या हल करने के कौशल की आवश्यकता है?

स्पष्ट रूप से हाँ, मैंने सोचा होगा।

Answer 4

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

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

Answer 5

अच्छा ओओ डिज़ाइन करने से पहले आपको खराब ओओ डिज़ाइन करना होगा।

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

• यह अनुभव से है डिजाइन कौशल प्राप्त किया जा सकता?

हां।

• विल इंटरनेट आदि मदद ढंग से सिखाया जाता किताबें/ब्लॉग/सामग्री?

हां।

• यह है कि एक आवेदन होने का डोमेन ज्ञान की जरूरत है विकसित की है?

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

• जानने डिजाइन पैटर्न, सिद्धांतों?

हां, हमेशा बेहतर होता है।

• अध्ययन 'कोड पूरा' किताब?

बहुत से लोग कहते हैं कि यह एक महान पुस्तक है। लेकिन, क्या आपने इटालो कैल्विनो पढ़ा है? या जॉर्ज लुइस बोर्गेस? सभी प्रकार की किताबें मदद कर सकती हैं।

• आवश्यकता समस्या को सुलझाने कौशल के लिए?

नहीं, आप OO (या किसी अन्य प्रतिमान) लगाने से समस्या को सुलझाने के कौशल मिलता है।

Answer 6

इसके अतिरिक्त आप क्लास डिज़ाइन को बेहतर बनाने के लिए इकाई परीक्षण का उपयोग कर सकते हैं।

Answer 7

मैं आपको स्मॉलटाक सीखने का सुझाव देता हूं। हां..मुझे पता है कि यह थोड़ा पुराना है, लेकिन मुझे लगता है कि यह ऑब्जेक्ट ओरिएंटेशन के साथ प्रयोग, सराहना और 'मज़ेदार' करने का एकमात्र वातावरण है।

आईडीटी से सब कुछ छोटी वस्तु में एक वस्तु है। आप हेडर/स्रोत फाइलों, संकलन आदि जैसे विवरणों के साथ समय बर्बाद किए बिना वस्तुओं के बारे में सोच सकते हैं।

डाउनलोड स्क्वीक स्मालटाक की एक प्रति (http://www.squeak.org/) और

Answer 8

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

Answer 9

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

फिर, अमूर्त से वस्तु उन्मुखीकरण के मौलिक सिद्धांतों इस प्रकार है: सार डेटा प्रकार, छुपा जानकारी आदि, और, विरासत आदि कैप्सूलीकरण की तरह उन्हें प्राप्त करने