आपको अपने ओओपी डिज़ाइन के लिए अच्छे अभ्यास कैसे मिले? [बन्द है]

Question

मुझे एहसास हुआ कि मुझे ओओपी डिज़ाइन बनाने में कठिनाई है। मैंने यह तय करने में कई समय बिताए कि क्या यह संपत्ति सही ढंग से एक्स क्लास के लिए निर्धारित है।

उदाहरण के लिए, यह एक ऐसी पोस्ट है जिसमें कुछ दिन हैं: /codereview/8041/how-to-improve-my-factory-design

मुझे अपने कोड पर यकीन नहीं है। इसलिए मैं अपने डिजाइन में सुधार करना चाहता हूं, इसे बनाने में कम समय लगेगा।

आपने अच्छे डिज़ाइन बनाना कैसे सीखा? कुछ किताबें जो आप मुझे सुझा सकते हैं?

Comments

आपका वर्तमान स्तर क्या है? मुझे लगता है कि आप डिजाइन पैटर्न के बारे में जानते हैं?

— एसीएनबी

बिल्कुल नहीं, वास्तव में, मैंने उनमें से कुछ को बहुवचन पाठ्यक्रम में पढ़ना शुरू किया: pluralsight-training.net/microsoft/Courses/…

— डार ज़ोन

सॉफ्टवेयर डिजाइन में सबसे प्रभावशाली पुस्तकों में '' डिजाइन पैटर्न: पुन: प्रयोज्य वस्तु-उन्मुख सॉफ्टवेयर के तत्व '' है। यह अभी भी पढ़ने लायक है, हालांकि अब यह थोड़ा दिनांकित है। आप [ en.wikipedia.org/wiki/Software_design_patternades(wikipedia लेख] पढ़ना भी शुरू कर सकते हैं । ये सॉफ़्टवेयर डिज़ाइन पैटर्न आपको न केवल सामान्य समस्याओं के लिए एक अच्छा समाधान प्रदान करते हैं, बल्कि अब पेशेवर शब्दावली का भी हिस्सा हैं।

— एसीएनबी

1. लिखें - 2. समीक्षा (साहित्य और पीएसई जैसी साइटों को पढ़ने सहित) - 3. रिफ्लेक्टर - 4. दोहराएं

— होरसकोल

अनुभव का कोई विकल्प नहीं है, इस तरह के ज्ञान में कोई कमी नहीं है

Answer 1

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

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

हालाँकि मैं आम तौर पर अन्य लोगों के साथ आमने-सामने बैठना सबसे अच्छा समझता हूँ, विशिष्ट डिजाइन प्रश्न यहाँ प्रोग्रामर से पूछे जा सकते हैं। कोड समीक्षा और कार्यान्वयन प्रश्नों के लिए स्टैक एक्सचेंज साइटें भी हैं ।

Answer 2

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

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

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

एक बात के लिए, डिज़ाइन पैटर्न के बारे में पढ़ना एक खराब शुरुआत है IMHO। OO डिजाइन सिद्धांतों के बारे में पढ़ना, जैसे कि SOLID और GRASP बेहतर है। उनसे परिचित होने के बाद, सामान्य डिजाइन पैटर्न का अध्ययन एक अच्छा विचार है, क्योंकि आप देखेंगे कि उन सिद्धांतों को ठोस मुहावरों के निर्माण के लिए कैसे लागू किया जा सकता है।

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

तो यहाँ मेरा सुझाव है:

1. कोड लिखें (और समझने की कोशिश करें कि यह क्या बुरा है)
2. कोड पढ़ें (और समझने की कोशिश करें कि इससे क्या अच्छा होता है)
3. अन्य लोगों के साथ ज्ञान का आदान-प्रदान करें। अपने विचारों को कसौटी पर कसें।

Comments

यह उत्कृष्ट सलाह है! मैं पूरी तरह से अपने डिजाइन पैटर्न ज्ञान को लागू करने के बिंदु पर हूं, जैसा कि केविन के साथ मेरी चर्चा में यहां

— TheSilverBullet

Answer 3

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

तथ्य यह है कि आप अपने सामान को देखते हैं और आपको जो लिखा है वह पसंद नहीं है, पहले से ही आपको हमारे पेशे में कई अन्य लोगों की तुलना में वक्र के आगे रखता है। जब आप अपने आप को बेहतर बनाने की कोशिश कर रहे हैं, तो हम में से बाकी लोग ऐसे लोगों के साथ काम करते हैं जो 20 मापदंडों के साथ 500-लाइन फ़ंक्शन लिखेंगे, सभी संदर्भों में पारित हो जाएंगे और उनमें से 15 को [बाहर / बाहर] और उन लोगों को लगता है कि वे बम हैं क्योंकि उन्हें वह गड़बड़ काम करने के लिए मिली थी।

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

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

शुरू करने के लिए मैं इन पुस्तकों की सिफारिश करूंगा:

• चुस्त सिद्धांत, पैटर्न और अभ्यास C # में - मैं स्वयं इस पुस्तक के माध्यम से 3 / 4th हूं। मुख्य बिंदुओं में से एक लेखक बनाता है, और मैं इसके साथ 100% सहमत हूं, आवेदन करने के लिए एक डिज़ाइन पैटर्न की तलाश करके समस्या को हल करना शुरू न करें। चीजों को जितना संभव हो उतना सरल रखें और कोड को एक पैटर्न में विकसित करें, अगर विकल्प इससे अधिक जटिल होने लगे।
• हेड फर्स्ट डिज़ाइन पैटर्न - मैंने इस पुस्तक को नहीं पढ़ा है और IMO में कई हेड फर्स्ट सीरीज़ को विशेष रूप से नए लोगों को क्षेत्र में लक्षित किया जाता है। इसलिए वे सरल पक्ष पर होते हैं, लेकिन मैंने उस पुस्तक के बारे में दूसरों से कई अच्छी प्रतिक्रियाएं सुनी / पढ़ी हैं

Comments

+1: "चीजों को जितना संभव हो उतना सरल रखें ..." "एक पैटर्न में कोड का विकास करें ..."

— kevin cline

Answer 4

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