सॉलिड सिद्धांतों और डिजाइन पैटर्न को समझने में प्रतीत नहीं होता

Question

मैं हाल ही में ओओपी में प्रवेश करने की कोशिश कर रहा हूं, और मुझे SOLID सिद्धांतों और डिजाइन पैटर्न के साथ समस्या हो रही है। मैं देखता हूं कि लोग उनका उपयोग क्यों करते हैं, और मैं वास्तव में भी उनका उपयोग करना चाहता हूं, लेकिन मैं अपने वर्गों को विनिर्देशों के विकास के आसपास अपने सिर को लपेट नहीं सकता। मैं वास्तव में ऐसी किसी भी चीज की सराहना करता हूं जो इस तरह की मेरी समझ में मदद करेगी।

Answer 1

मैंने कॉलेज में एक कक्षा ली है जो डिजाइन पैटर के आसपास दो सप्ताह बिताती है, और Gang of Four पुस्तक को कोई फायदा नहीं हुआ। फिट करने के लिए प्रत्येक पैटर्न के लिए क्या उपयोग किया जाता है और उन्हें कैसे उपयोग किया जाए, यह समझना मेरे समस्याएं मेरे लिए बहुत कठिन थीं, एक डेवलपर जिसे ओओ प्रोग्रामिंग में अधिक अनुभव नहीं था।

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

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

आइए के बारे में ठोस बात:

1. एकल जिम्मेदारी। एक वर्ग में केवल एक जिम्मेदारी होनी चाहिए। इसका मतलब है कि उदाहरण के लिए, एक व्यक्ति वर्ग को केवल व्यक्ति के संबंध में डोमेन समस्या के बारे में चिंता करनी चाहिए, न कि उदाहरण के लिए, डेटाबेस में इसकी दृढ़ता। इसके लिए, आप उदाहरण के लिए एक PersonDAO का उपयोग करना चाह सकते हैं। एक व्यक्ति वर्ग अपनी जिम्मेदारियों को सबसे कम रख सकता है। यदि कोई वर्ग बहुत अधिक बाहरी निर्भरताओं (यानी, अन्य वर्गों) का उपयोग कर रहा है, तो यह एक लक्षण है कि कक्षा में बहुत अधिक जिम्मेदारियां हैं। यह समस्या अक्सर तब आती है जब डेवलपर्स ऑब्जेक्ट्स का उपयोग करके वास्तविक दुनिया का मॉडल करने की कोशिश करते हैं और इसे बहुत दूर ले जाते हैं। कमजोर युग्मित अनुप्रयोग अक्सर नेविगेट करने के लिए बहुत आसान नहीं होते हैं और वास्तव में वास्तविक दुनिया का काम नहीं करते हैं।
2. खुला बंद। कक्षाएं विस्तारित होनी चाहिए, लेकिन संशोधित नहीं होनी चाहिए। इसका मतलब है कि कक्षा में एक नया क्षेत्र जोड़ना ठीक है, लेकिन मौजूदा चीजों को बदलना नहीं है। कार्यक्रम पर अन्य घटक कहा क्षेत्र पर निर्भर कर सकते हैं।
3. लिस्कोव प्रतिस्थापन। एक वर्ग जो कि प्रकार के जानवर की वस्तु की अपेक्षा करता है, यदि उप-वर्ग कुत्ता और उप-वर्ग बिल्ली पारित हो जाती है। इसका मतलब है कि पशु को उदाहरण के लिए छाल नामक विधि नहीं होनी चाहिए, क्योंकि टाइप बिल्ली के उप-वर्ग छाल में सक्षम नहीं होंगे। कक्षा वर्ग का उपयोग करने वाली कक्षाओं को भी कक्षा कुत्ते से संबंधित विधियों पर निर्भर नहीं होना चाहिए। ऐसी चीजें न करें जैसे "यदि यह जानवर कुत्ता है, तो जानवर (कुत्ते को जानवर को रोकता है) छाल। यदि जानवर एक बिल्ली है (बिल्ली को जानवर को जानवर देता है) मेयो"।
4. इंटरफेस पृथक्करण सिद्धांत। अपने इंटरफेस को सबसे छोटा रखें जो आप कर सकते हैं। एक शिक्षक जो छात्र भी है, उसे ISTudentAndTeacher नामक एक बड़े इंटरफ़ेस के बजाय, इश्यूडेंट और आईटाइचर इंटरफेस दोनों को लागू करना चाहिए।
5. निर्भरता उलटा सिद्धांत। वस्तुओं को उनकी निर्भरताओं को तुरंत शुरू नहीं करना चाहिए, लेकिन उन्हें उन्हें पारित किया जाना चाहिए। उदाहरण के लिए, एक कार जिसमें इंजन ऑब्जेक्ट है, उसे इंजन = नया डीज़ेलइंजिन() नहीं करना चाहिए, बल्कि इंजन ने इसे कन्स्ट्रक्टर पर पास किया जाना चाहिए। इस तरह कार वर्ग डीजलइंजिन कक्षा के साथ नहीं जोड़ा जाएगा।