आठ प्रोग्रामिंग सिद्धांत जो आपके जीवन को आसान बना सकते हैं

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

1. क्या बदल रहा है समझाया।
यह सभी OOP की नींव है। उन घटकों की पहचान करना आवश्यक है जो बदल सकते हैं, और उन्हें सिस्टम के हिस्से से अलग करने के लिए जो अपरिवर्तित रहेंगे। एनकैप्सुलेशन आपको चयनित घटकों को बाकी सिस्टम को बदलने के बिना बदलने या विस्तारित करने की अनुमति देता है। यहां मुख्य समस्या यह है कि एप्लिकेशन को भागों में विभाजित करना सबसे अच्छा कैसे है। सभी डिज़ाइन पैटर्न इस प्रश्न के उत्तर से निपटते हैं।

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

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

private ArrayList < String > someList = new ArrayList < String > ();

लिखने की जरूरत है:

private List < String > someList= new ArrayList < String > ();

तदनुसार, एक्सेसर्स में, विधि कॉल में, कार्यान्वयन के बजाय अमूर्त का उपयोग किया जाना चाहिए। अब यदि आवश्यक हो, तो सूची के व्यवहार को दोहरे रूप से जोड़ने के लिए बदलें, यह केवल एक पंक्ति को बदलने के लिए पर्याप्त है:

private List < String > someList= new LinkedList < String > ();

4. अंतःक्रियात्मक वस्तुओं की कमजोर कनेक्टिविटी के लिए प्रयास करना।
कम ऑब्जेक्ट्स एक दूसरे के बारे में जानते हैं, सिस्टम जितना लचीला होता है। एक घटक को दूसरे की आंतरिक संरचना के बारे में जानने की आवश्यकता नहीं है।

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

6. केवल करीबी दोस्तों के साथ बातचीत करें।
यह न्यूनतम जागरूकता का सिद्धांत है। कक्षा डिजाइन करते समय, किसी को उन कक्षाओं की संख्या पर ध्यान देना चाहिए जिनके साथ इसकी बातचीत होगी। ऐसी कक्षाएं जितनी कम होंगी, सिस्टम उतना ही लचीला होगा।

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

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

लगभग सभी सिद्धांत एक-दूसरे के साथ प्रतिच्छेद करते हैं, सभी का एक ही कार्य है - प्रणाली की जटिलता को कम करना और, परिणामस्वरूप, प्रोग्रामर का जीवन। मैं विश्वास करना चाहता हूं कि किसी व्यक्ति का जीवन पढ़ने के बाद आसान हो जाएगा =)

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