👨‍🎤 👈🏾 🤞🏼 डिजाइन सिद्धांतों के पदानुक्रम, या इंजीनियरों के लिए सबसे महत्वपूर्ण शब्द 📎 👨🏽‍✈️ ☝🏽

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

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

और सबसे बुनियादी के रूप में, मैं "जटिलता का प्रबंधन / तकनीकी जटिलता को कम करने" के सिद्धांत पर विचार करना उचित समझता हूं। मैककॉनेल। और जटिलता को कम करने के सबसे महत्वपूर्ण तरीके प्रतिरूपता और अमूर्तता हैं।

इस लघु लेख में कई खंड शामिल होंगे:

पदानुक्रम का शासन
पदानुक्रम अवलोकन
टिप्पणी
परिणाम

पदानुक्रम का शासन

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

पदानुक्रम अवलोकन

इसलिए, उन कुछ डिज़ाइन सिद्धांतों के बारे में जो मुझे पता है, मैं निम्नलिखित स्तरों पर रहना पसंद करता हूँ:

तकनीकी जटिलता को कम करें
प्रतिरूपकता और अमूर्तता; यह सरल रखें, बेवकूफ (चुंबन) ; अपने आप को मत दोहराओ (DRY)
प्रक्रियात्मक प्रोग्रामिंग; PLO; परीक्षण-संचालित विकास (TDD) ; डोमेन-संचालित डिज़ाइन (DDD)
डिजाइन पैटर्न ( फाउलर , गैंग ऑफ फोर , एमवीसी ); ठोस

तस्वीर में, यह इस तरह दिखेगा (चित्र में पदानुक्रमित संबंध शामिल हैं, जो उपरोक्त सूची के अनुकूल है):

टिप्पणी

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

तकनीकी जटिलता का न्यूनतमकरण

तकनीकी जटिलता (पाठ्यक्रम की आवश्यक कार्यक्षमता को संरक्षित करते हुए) की जटिलता प्रबंधन / न्यूनतमकरण क्या है और इसे मूल डिजाइन सिद्धांत क्यों माना जा सकता है, यह स्टीव मैककोनेल की सुंदर पुस्तक "कोड कम्प्लीट", अध्याय 5 में पाया जा सकता है। चर्चा के साथ शुरू होता है शब्द "जटिलता प्रबंधन", लेकिन मुझे व्यक्तिगत रूप से यह कम जानकारीपूर्ण लगता है।

KISS सिद्धांत कुछ अर्थों तकनीकी जटिलता को कम करने के समान है, लेकिन बाद से वहाँ एक अलग परिवर्णी शब्द है, मैं भी यह इसके लिए एक विशेष ब्लॉक आरेख में शामिल थे।

मॉड्यूल और अमूर्तता, या इंजीनियरों के लिए सबसे महत्वपूर्ण शब्द

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

इसलिए, मैं प्रतिरूपकता और अमूर्तता पर अधिक विस्तार से ध्यान देना चाहूंगा - उत्कृष्ट पुस्तक " कंप्यूटर प्रोग्राम की संरचना और व्याख्या " में चर्चा की गई अवधारणाएं (SICP; पहला संस्करण सार्वजनिक डोमेन में है, दूसरा नहीं है)। यह पुस्तक, जो, मेरी राय में, इंजीनियरों के लिए सबसे महत्वपूर्ण शब्द है।

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

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

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

परीक्षण-संचालित विकास और डोमेन-संचालित डिज़ाइन

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

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

परिणाम

उचित विकास प्राथमिकताएं

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

पेशेवर विकास और प्रशिक्षण (जूनियर कर्मचारियों या छात्रों) के लिए सही प्राथमिकताएं

डिजाइन सिद्धांतों के पदानुक्रम, मुझे आशा है, कई तथ्य स्पष्ट करेंगे:

कनिष्ठ अभियंता को OOP के बारे में एक पुस्तक की सिफारिश करने से पहले, एक पुस्तक को मॉड्यूलरिटी और अमूर्तता के बारे में देना बेहतर होगा (उदाहरण के लिए, SICP)
डिजाइन पैटर्न के बारे में एक पुस्तक की सिफारिश करने से पहले, OOP के बारे में एक पुस्तक देना बेहतर है
आदि

मौजूदा प्रौद्योगिकियों की बेहतर समझ

उदाहरण के लिए, ओओपी केवल अमूर्त स्तर बनाने का साधन नहीं है, और यह प्रक्रियात्मक प्रोग्रामिंग एक ही उद्देश्य के लिए है।

आपके ध्यान के लिए आप सभी का धन्यवाद!

पुनश्च

सामान्य तौर पर, चूंकि मैंने SICP का विज्ञापन किया था, इसलिए मुझे जादूगर की पुस्तक भी कहा जाता है, इस लेख में, संपूर्णता के लिए, मैं सिंड्रेला की पुस्तक और ड्रैगन की पुस्तक की सिफारिश करता हूं, जो कम मौलिक नहीं हैं। तो, शानदार पुस्तकों की एक सूची:

फिर से, कई लोगों के लिए, ये किताबें आम तौर पर (विशेषकर ड्रैगन बुक) प्रतीत होंगी, लेकिन, मेरा मानना है कि ऐसे कई लोग होंगे जो इस लेख में पहली बार उनके बारे में पढ़ेंगे।

डिजाइन सिद्धांतों के पदानुक्रम, या इंजीनियरों के लिए सबसे महत्वपूर्ण शब्द