प्रोग्रामिंग ठोस सिद्धांतों

समय के साथ मैं एसओएलआईडी के दो हिस्सों को समझ सकता था - "एस" और "ओ"।

"O" - मैंने इनहेरिटेंस और स्ट्रैटेजी पैटर्न की मदद से ओपन क्लोज्ड सिद्धांत सीखा।

"S" - मैंने ORM सीखते समय सिंगल रिस्पॉन्सिबिलिटी सिद्धांत सीखा (दृढ़ता का तर्क डोमेन ऑब्जेक्ट्स से दूर ले जाया जाता है)।

इसी तरह, SOLID के अन्य भागों ("L", "I" और "I") को सीखने के लिए सबसे अच्छे क्षेत्र / कार्य क्या हैं?

संदर्भ

object-oriented solid

— LCJ
स्रोत

ध्यान दें कि ये सभी विचार अच्छे विचार हैं, और साथ में वे बहुत अच्छे हैं। लेकिन अगर आप उन्हें हठधर्मिता से लागू करते हैं तो वे सफलता की तुलना में अधिक असफल हो जाएंगे।

OR-Mappers चिंताओं के पृथक्करण के लिए अच्छे हैं, एकल जिम्मेदारी सिद्धांत नहीं। मतभेदों की चर्चा के लिए इस पोस्ट प्रोग्रामर को देखें ।stackexchange.com/questions/ 155628/… ।

— डॉक्टर ब्राउन

वास्तविक दुनिया उदाहरण blog.gauffin.org/2012/05/…

— LCJ

@JarrodRoberson हां, यही कारण है कि उन्हें सावधानीपूर्वक दिशानिर्देश के रूप में संदर्भित किया जाता है । बाकी सिद्धांतों को भी न भूलें: adamjamesnaylor.com/2012/11/12/… (कुल 11 में)

— एडम नेल्लोर

@AdamNaylor का लिंक अब 404 है, इसे adamjamesnaylor.com/post/… पर

— मैटमोटू

जवाबों:

मैं कुछ महीने पहले आपके जूते में था जब तक मुझे एक बहुत ही उपयोगी लेख नहीं मिला।

प्रत्येक सिद्धांत को वास्तविक दुनिया की स्थितियों के साथ अच्छी तरह से समझाया गया है जो प्रत्येक सॉफ्टवेयर डेवलपर अपनी परियोजनाओं में सामना कर सकता है। मैं यहां छोटी कटौती कर रहा हूं और संदर्भ की ओर इशारा कर रहा हूं - ठोस सॉफ्टवेयर विकास, एक समय में एक कदम ।

जैसा कि टिप्पणियों में कहा गया है, एक और बहुत अच्छी पीडीएफ रीडिंग है - पाब्लो का सॉलिड सॉफ्टवेयर डेवलपमेंट ।

इसके अलावा, कुछ अच्छी किताबें हैं जो अधिक जानकारी में SOLID सिद्धांतों का वर्णन करती हैं - SOLID सॉफ़्टवेयर डेवलपमेंट पर अच्छी पुस्तक ।

प्रत्येक सिद्धांत के लिए एक संक्षिप्त सारांश का संपादन और टिप्पणियाँ:

"एस" - एकल उत्तरदायित्व सिद्धांत परिवर्तन की अनुमति देने के लिए व्यवसाय की जरूरतों से प्रेरित है। "बदलने का एक एकल कारण" आपको यह समझने में मदद करता है कि अकेले तकनीकी अवधारणा के बजाय, व्यवसायिक अवधारणा और संदर्भ पर विचार करके तार्किक रूप से अलग-अलग अवधारणाओं को एक साथ रखा जाना चाहिए। In another words, मैंने सीखा कि प्रत्येक वर्ग की एक ही जिम्मेदारी होनी चाहिए। जिम्मेदारी सिर्फ सौंपे गए कार्य को पूरा करने की है
"ओ" - मैंने ओपन क्लोज्ड सिद्धांत सीखा और "विरासत पर रचना को प्राथमिकता देना" शुरू किया और इस तरह, उन कक्षाओं को प्राथमिकता दी जिनके पास कोई आभासी विधियां नहीं हैं और संभवतः सील हैं, लेकिन उनके विस्तार के लिए सार पर निर्भर हैं।
"एल" - मैंने डेटा एक्सेस के प्रबंधन के लिए रिपॉजिटरी पैटर्न की मदद से लिस्कोव सबस्टीट्यूशन सिद्धांत सीखा।
"मैं" - मैंने इंटरफ़ेस अलगाव के सिद्धांत के बारे में यह जानकर सीखा कि क्लाइंट को उन इंटरफेस को लागू करने के लिए मजबूर नहीं किया जाना चाहिए, जिनका वे उपयोग नहीं करते हैं (जैसे ASP.NET 2.0 में सदस्यता प्रदाता)। तो इंटरफ़ेस में "बहुत सारी जिम्मेदारियां नहीं" होनी चाहिए
"डी" - मैंने डिपेंडेंसी इनवर्सन प्रिंसिपल के बारे में सीखा और कोड को बदलना शुरू कर दिया जो कि बदलना आसान है । बदलने के लिए आसान स्वामित्व और उच्च रखरखाव की कम लागत का मतलब है।

कोडप्लेक्स से एक उपयोगी संसाधन के रूप में टिप्पणियों में उल्लेख किया गया था, उदाहरण के लिए SOLID में संदर्भ शामिल है

— एल युसुबोव
स्रोत

मुझे लेखों का निम्नलिखित संग्रह बहुत उपयोगी लगा: Lostechies.com/wp-content/uploads/2011/03/…

— Scroog1

मैंने वह पूरा लेख पढ़ा और मैं पैटर्न पर या एसओएलआईडी पर नहीं बेचा गया। उदाहरण बहुत सरल है, लेकिन जब यह जटिल हो जाता है कि जटिलता कृत्रिम है। मुझे बेहतर विकल्पों के बिना वास्तविक दुनिया के एकमात्र OOP से सामना करना बाकी है।

— जॉब

चूँकि खोई हुई वस्तुओं के लेखों का उल्लेख किया गया था, इसलिए यह भी वहाँ है solidexamples.codeplex.com ( गुमठियों के आधार पर)

— अंधेरे पिता

मैं पाब्लोस ईबुक के योगदानकर्ताओं में से एक था। मुझे खुशी है कि लोग अभी भी इसे उपयोगी पाते हैं। :)

— शॉन चैंबर्स

+1000000 अगर मैं ओपन-क्लोज़्ड सिद्धांत के आपके सारांश के लिए कर सकता हूं - हर कोई यह गलत हो जाता है और सोचता है कि यह विरासत के बारे में है

— एलेक्सफॉक्सगिल

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

— StriplingWarrior
स्रोत

+1 यह बहुत सच है। आपको कभी-कभी (imo) का पालन करने की भी आवश्यकता नहीं होती है 'एक इकाई परीक्षण केवल एक चीज का परीक्षण करना चाहिए' नियम: यदि आप एक मिनट में एक वर्ग के लिए एक सभ्य परीक्षण सूट के साथ नहीं आ सकते हैं, तो यह I और D का उल्लंघन करता है और शायद बाकी

— अल्फबेट का

Liskov प्रतिस्थापन सिद्धांत मूल रूप से आपको कार्यान्वयन विरासत से अधिक उपयोग करने की अनुमति नहीं देता है: आपको कोड पुन: उपयोग के लिए विरासत का उपयोग कभी नहीं करना चाहिए (इसके लिए संरचना है)! एलएसपी का पालन करने से, आप यह सुनिश्चित कर सकते हैं कि वास्तव में आपके सुपरक्लास और आपके उपवर्ग के बीच "एक-एक संबंध" मौजूद है।

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

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

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

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

— m3th0dman
स्रोत

लिस्कोव पर महान व्याख्या। :)

— जॉन कोर्न्स