वास्तव में कैसे पता लगाया जाए कि ऑब्जेक्ट ओरिएंटेड डिज़ाइन में क्या किया जाना है?


12

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

जब मैंने PHP का अध्ययन किया तो मैंने 2009 में प्रोग्राम करना सीख लिया। बाद में 2012 में, मैं C # और .NET में चला गया। वैसे भी, कोडिंग समस्या नहीं है, नीचे एल्गोरिदम लिखना मेरी समस्या नहीं है। मेरी वास्तविक समस्या यह जानना है कि किसी आवश्यकता को प्राप्त करने के लिए क्या कोडित किया जाना है और इसे कहां कोडित किया जाना है।

वेब पर उपलब्ध अधिकांश पाठ्यक्रम कैसे - एक निश्चित भाषा में कोड कैसे लिखें, एपीआई के कुछ सेट का उपयोग कैसे करें, आदि से निपटा करते हैं । यह मेरी बात नहीं है।

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

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

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

अधिकांश समय, बहुत अधिक विचार के साथ मैं कुछ विचारों के साथ समाप्त होता हूं, लेकिन मुझे कभी नहीं पता है कि मेरा विचार सही है या नहीं, कैसे निर्णय लें।

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

तो मैं कैसे सीख सकते हैं वास्तव में कर वस्तु उन्मुख डिजाइन? मैं जो सीखना चाहता हूं वह यह है: दी गई आवश्यकताओं को पता है कि उन पर काम करना कैसे शुरू करें एक प्रक्रिया है जो यह पता लगाने की ओर ले जाती है कि क्या करना है और प्रत्येक कोड कहां का है। अगर मेरा विचार सही है या नहीं तो मैं कैसे जज करना सीख सकता हूँ?

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


1. क्या आप पहले से ही C # की सभी मूलभूत अवधारणाओं को समझते हैं, जिसमें ऑपरेटर ओवरलोडिंग बनाम ऑपरेटर ओवरराइडिंग के बीच का अंतर जैसी चीजें शामिल हैं, एक अमूर्त वर्ग क्या है और यह एक इंटरफेस, इनकैप्सुलेशन, बहुरूपता आदि से कैसे अलग है? O # को C # में पूरी तरह से समझने के लिए पहले इन बातों को जानना आवश्यक है। देखें c-sharpcorner.com/technologies/oop-ood
रॉबर्ट हार्वे

2
2. Winforms में लिखे गए पुराने एप्लिकेशन मिट्टी की बड़ी गेंदों में बदल जाते हैं, जब तक कि उन्हें ठीक से आर्किटेक्चर नहीं किया जाता है। चिंताओं का पृथक्करण सर्वोपरि है। देखें winformsmvp.codeplex.com
रॉबर्ट हार्वे

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

1
थोड़ा शुरू करो। आवश्यकताएँ समस्याएँ हैं। एक समस्या जितनी बड़ी हो सकती है, "हम अगली Stackexchange साइट को विकसित करना चाहते हैं" या जितनी कम हो सके "हम चाहते हैं कि हमारा अगला Stackexchange लॉगिन हो।" एक बड़ी समस्या को बहुत से लेकिन छोटे लोगों में बदल दें। कुल मिलाकर, अपने आप को पहले "गलत" चीजों को करने और समय के साथ सुधार करने का मौका दें।
लैवि

1
मैं साथ-साथ इसे आगे
बढ़ाना

जवाबों:


21

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

खैर सबसे पहले, ऑब्जेक्ट ओरिएंटेड डिज़ाइन को सही मानकर सोचना बंद करें। यह अंग्रेजी के सही होने के बारे में सोचने जैसा है।

ऑब्जेक्ट ओरिएंटेड प्रतिमान सही नहीं है। इसके कुछ फायदे और नुकसान हैं। यह एक आदर्श है। यह केवल हमारा नहीं है। यह कुछ भी नहीं से बेहतर है, लेकिन यह निश्चित रूप से सब कुछ नहीं है।

मैं दशकों से कोडिंग कर रहा हूं। मैंने इस सामान का लगभग अध्ययन किया है क्योंकि यह विचार मौजूद है। मैं अभी भी सीख रहा हूं कि इसका क्या मतलब है। विशेषज्ञ अभी भी सीख रहे हैं कि इसका क्या मतलब है। हमारा पूरा क्षेत्र 100 साल से कम पुराना है।

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

समस्या यह है कि हम वह सब करने के लिए भुगतान नहीं कर रहे हैं। हम वह सब करते हैं क्योंकि हम पेशेवर हैं। हमें वह सब करना होगा जब बॉस नहीं दिख रहा है क्योंकि हमेशा एक समय सीमा है। लेकिन हम 5 साल में वापस आना चाहते हैं और नए लोगों से कहना चाहते हैं: "ओह, हाँ, मैंने लिखा है। अभी भी काम करता है हुह? कूल।"

तुम्हें वहां कैसे मिलता है? अभ्यास। विश्वास पर किसी भी डिजाइन विचार को स्वीकार न करें। किसी ने इस बारे में बंद नहीं किया कि किस तरह से संचालित डिजाइन इस डिजाइन को सरल करेगा? यकीन नहीं होता कि वे सही हैं? घर पर अपनी खुद की खिलौना परियोजना बनाएं जो पर्यवेक्षक पैटर्न का उपयोग करता है। इसके साथ मेस करें। उन चीजों को खोजने की कोशिश करें जिनके साथ यह मदद नहीं करता है।

पढ़ें। सवाल। परीक्षा। दोहराएँ।

जब आप उस बिंदु पर पहुंच जाते हैं, जो आप कर रहे हैं, तो अपने जीवन के 80% के लिए आप बस उतने ही भ्रमित होंगे जितना मैं हूं।

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

मुझे भी ऐसा ही लगता था। तब मैंने रिफैक्टिंग की खुशी का पता लगाया। आप कोड के रूप में डिजाइन को अनुकूलित करने के लिए तैयार रहें। समय से पहले कागज पर सब कुछ काम करने की कोशिश करना कठिन तरीका है। ऐसा कोड लिखें जो गलत साबित हो सकता है, इसे गलत साबित कर सकते हैं, और इसे ठीक कर सकते हैं।


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

जवाब के लिए धन्यवाद! तो आपकी बात यह है: एक बार हमारे पास आवश्यकता को लागू करने के लिए कम से कम एक समाधान होता है, और यह काम करता है, हम इसे लागू करते हैं, और फिर जैसा कि हम देखते हैं कि यह दूसरे कोड और अन्य आवश्यकताओं से कैसे संबंधित है, हम इसे बेहतर बनाने के लिए इसे रिफैक्ट करते हैं? लेकिन अभी भी ऐसी परिस्थितियां हैं जहां मुझे कुछ आवश्यकताएं मिलती हैं और मुझे नहीं पता कि कैसे शुरू किया जाए। उस स्थिति में, क्या आपके पास कोई सलाह है कि कैसे भी शुरू करें? कभी-कभी मेरा मानना ​​है कि आवश्यकताओं और संभावित कार्यान्वयन पर चर्चा करना सबसे अच्छा होगा, लेकिन मैं अकेले काम करता हूं। क्या कोई मंच है जहां इस तरह की चर्चा का स्वागत है?
user1620696

2
अच्छा पहले, अकेले काम करना बंद करो। यहां तक ​​कि एक नौसिखिया नौसिखिया होना जो चीजों को समझाने के लिए आपको धीमा कर देता है, उससे बेहतर है। दूसरा भागों में एक आवश्यकता को तोड़ना सीखता है। ऐसा करते रहो कि जब तक आपके पास कुछ प्रबंधनीय न हो, जिस पर आप कर्षण प्राप्त कर सकते हैं। अगर आपको करना है तो पूरी तरह से अलग माहौल में अवधारणा कोड का प्रमाण लिखें। बस कुछ ऐसा करें जो आपकी समझ को व्यक्त करे जो आवश्यक है। फिर उस अभिव्यक्ति का परीक्षण करें। तुम मेरी पाते हो कि तुमने बुरी धारणाएँ बना लीं। अच्छी बात है। उन्हें बदलने के लिए तैयार रहें।
कैंडिड_ऑरेंज

1

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

पाठ्यक्रम की समस्या यह है कि नए नए ग्रीनफील्ड कोड लिखना विरासत कोड को बनाए रखने की तुलना में बहुत सस्ता और आसान है, इसलिए कोड गुणवत्ता या वास्तुकला पर बहुत अधिक लटकाए जाने के बजाय, याद रखें कि आपकी वास्तविक समस्या रखरखाव है।

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

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

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

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

आपको विशेष रूप से एक सख्त विकास पद्धति का पालन करने की आवश्यकता नहीं है जैसे कि टीडीडी / बीडीडी को पर्याप्त स्वचालित परीक्षणों के साथ समाप्त करने के लिए ताकि आप रिफ्लेक्टर की अनुमति दे सकें; आपको भविष्य में आकस्मिक रूप से टूटने वाले परिवर्तनों के खिलाफ कोड की रक्षा करने के लिए पर्याप्त आवश्यकता है

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

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

बेशक, कभी-कभी आपके पास इकाई परीक्षण लिखने के लिए समय नहीं होता है; हालाँकि, यदि आपने प्रश्न को ध्यान में रखते हुए अपने सभी कोड लिखे हैं "मैं इसके लिए स्वचालित परीक्षण कैसे लिखूं?" (यहां तक ​​कि अगर आपने वास्तव में उन परीक्षणों को लागू नहीं किया है), तो आप संभवतः एक ऐसा डिज़ाइन ढूंढने में भी कामयाब रहे हैं जो काफी हद तक कायम है।


1
हमारे पास कभी भी स्वचालित परीक्षण लिखने का समय नहीं होता है, लेकिन हमारे पास हमेशा समय-समय पर मैन्युअल परीक्षण चलाने का समय होता है ...
Nick Keighley

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

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

1
@BenCottrell - मैं पूरी तरह से सहमत हूँ। कोड को हमेशा संशोधित करने की आवश्यकता होगी। हालाँकि, इसकी वजह से, यह लोगों को "अपफ्रंट डिज़ाइन" करने के लिए समय निकालने और कुछ प्रकार की विफलता के रूप में "क्लीन कोड" लिखने की ओर ले जाता है। वे खराब कोड / डिज़ाइन को सही ठहराने के लिए "ऑन-टाइम" और "ऑन-बजट" मंत्र का उपयोग करते हैं। आप उन सभी "प्रथाओं" का उपयोग कर सकते हैं जो आप चाहते हैं, लेकिन यह आपको खरीदने के लिए नहीं जा रहा है "कोड जो कि आसान और सस्ता है" को बिना अच्छे डिज़ाइन और अपेक्षाकृत "क्लीन कोड" के साथ शुरू करने के लिए। एक अच्छा डिज़ाइन और "क्लीन कोड" वास्तव में ऑन-टाइम और ऑन-बजट लक्ष्य को प्राप्त करने का उप-उत्पाद होगा।
डंक

@ डंक ऐसा लगता है कि आप कह रहे हैं कि कई डेवलपर्स कोड गुणवत्ता के बारे में परवाह नहीं करते हैं, जो मुझे नहीं लगता कि आमतौर पर ऐसा होता है। वास्तव में, मुझे लगता है कि दो बड़ी समस्याएं हैं - सबसे पहले, जबकि डेवलपर्स वे हो सकते हैं जो बजट और समय सीमा के लिए एक अनुमान प्रदान करते हैं, अनुमान आसानी से गलत हो सकते हैं। दूसरे, परियोजना हितधारकों को समय / लागत पर अंतिम कहना है, जिसका अर्थ है कि जोखिम, बजट और समय सीमा तकनीकी चिंताओं से अधिक है। "निश्चित रूप से देर से / अधिक बजट" या "संभावित रूप से खराब कोड" के बीच एक विकल्प को देखते हुए, मुझे लगता है कि हितधारक अक्सर बाद का चयन करते हैं।
बेन कॉटरेल
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.