डिज़ाइन पैटर्न के लिए कितने सिद्धांत हैं?

सबसे पहले सारांशित डिज़ाइन पैटर्न केवल 5 थे, यानी SOLID:

• एकल उत्तरदायित्व सिद्धांत (Single Responsibility Principle, SRP): एक वर्ग को केवल एक ही कारण होना चाहिए जिससे बदलाव आए, यानी एक वर्ग को केवल एक ही उत्तरदायित्व होना चाहिए।
• ओपन/क्लोज्ड सिद्धांत (Open/Closed Principle, OCP): सॉफ्टवेयर एंटिटी (क्लास, मॉड्यूल, फ़ंक्शन आदि) को विस्तार के लिए खुला होना चाहिए, और संशोधन के लिए बंद होना चाहिए, यानी बदलाव को मौजूदा कोड में संशोधन करने के बजाय विस्तार के माध्यम से लागू किया जाना चाहिए।
• लिस्कोव प्रतिस्थापन सिद्धांत (Liskov Substitution Principle, LSP): उपप्रकार अपने आधार प्रकार को प्रतिस्थापित करने में सक्षम होना चाहिए, यानी व्युत्पन्न वर्ग अपने आधार वर्ग को प्रतिस्थापित कर सकता है बिना प्रोग्राम की सहीता को प्रभावित किए।
• इंटरफ़ेस अलगाव सिद्धांत (Interface Segregation Principle, ISP): क्लाइंट को उनके द्वारा उपयोग न किए जाने वाले इंटरफ़ेस पर निर्भर नहीं होना चाहिए। बड़े इंटरफ़ेस को छोटे, अधिक विशिष्ट इंटरफ़ेस में विभाजित किया जाना चाहिए ताकि क्लाइंट को केवल उन विधियों की आवश्यकता हो जिनका उपयोग वे करने जा रहे हैं।
• निर्भरता उलटा सिद्धांत (Dependency Inversion Principle, DIP): उच्च स्तरीय मॉड्यूल को कम स्तरीय मॉड्यूल पर निर्भर नहीं होना चाहिए, दोनों को अमूर्तता पर निर्भर होना चाहिए। अमूर्तता को विशिष्ट कार्यान्वयन विवरण पर निर्भर नहीं होना चाहिए, विशिष्ट कार्यान्वयन विवरण को अमूर्तता पर निर्भर होना चाहिए।

बाद में दो नियम जोड़े गए, जो अधिक विशिष्ट और अधिक मार्गदर्शक हैं। हम नियमों की व्याख्या से देख सकते हैं कि SOLID वर्णन करता है कि क्या करना चाहिए, जबकि बाद में जोड़े गए नियम वर्णन करते हैं कि प्राथमिकता/सबसे अच्छा क्या करना चाहिए।

• संयोजन/संचय पुन:उपयोग सिद्धांत (Composition/Aggregation Reuse Principle, CARP): कोड पुन:उपयोग के लिए वंशावली की तुलना में ऑब्जेक्ट संयोजन (संश्लेषण) और संचय को प्राथमिकता दी जानी चाहिए।
• डेमेटर का नियम (Law of Demeter, LoD): एक ऑब्जेक्ट को अन्य ऑब्जेक्ट की आंतरिक संरचना और कार्यान्वयन विवरणों को जितना हो सके कम जानना चाहिए।

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

• न्यूनतम ज्ञान सिद्धांत (Principle of Least Knowledge, PoLK): इसे डेमेटर के नियम के विस्तार के रूप में भी जाना जाता है, जो दावा करता है कि एक ऑब्जेक्ट को अन्य ऑब्जेक्ट की जानकारी को न्यूनतम सीमा तक रखना चाहिए। इस सिद्धांत का उद्भव 1987 में पैट्रिशिया लैगो (Patricia Lago) और कूस विसर (Koos Visser) द्वारा प्रस्तावित “न्यूनतम संचार नियम” तक जाता है।
• स्थिर निर्भरता सिद्धांत (Stable Dependencies Principle, SDP): इस सिद्धांत में कहा गया है कि सॉफ़्टवेयर डिज़ाइन को यह सुनिश्चित करना चाहिए कि स्थिर घटक अस्थिर घटकों पर निर्भर न हों, यानी स्थिरता वाले घटक अस्थिरता वाले घटकों पर कम निर्भर करें। इस सिद्धांत का विचार सॉफ़्टवेयर सिस्टम में घटकों के बीच संबंधों के गहन अध्ययन से उत्पन्न हुआ।
• स्थिर अमूर्तता सिद्धांत (Stable Abstraction Principle, SAP): स्थिर निर्भरता सिद्धांत के साथ प्रतिध्वनित करते हुए, यह सिद्धांत अमूर्तता को स्थिरता के साथ मिलाने का मार्गदर्शन करता है, यानी स्थिर घटक अमूर्त होने चाहिए, और अस्थिर घटक विशिष्ट होने चाहिए। यह सिद्धांत सॉफ़्टवेयर सिस्टम की स्थिरता और लचीलेपन को सुनिश्चित करने में मदद करता है।

• ←पिछला
• अगला→