डिजाइन के बारे में। भाग 2. व्यावहारिक उदाहरण

जैसा कि हमने पिछली बार चर्चा की थी , डिजाइन की चीज सरल नहीं है; लगातार सभी प्रकार के विकल्पों का एक गुच्छा ध्यान में रखना है और कई अलग-अलग आवश्यकताओं के बीच एक समझौता खोजने की कोशिश करना है जो आपके सुरुचिपूर्ण समाधान को अलग करते हैं। एक तरफ, मैं चाहता हूं कि उच्च प्रदर्शन के साथ समाधान को बनाए रखना आसान हो, अच्छी तरह से एक्स्टेंसिबल हो, और यह न केवल इसके लेखक के लिए, बल्कि कम से कम एक अन्य व्यक्ति के लिए भी स्पष्ट होना चाहिए; मैं चाहता हूं कि छोटी मेमोरी खाने का समाधान और OOP के 100 500 सिद्धांतों में से किसी का भी उल्लंघन न हो और, सबसे महत्वपूर्ण बात, हम इसे कम से कम इस साल खत्म करना चाहते हैं, हालांकि प्रबंधक लगातार जोर देकर कहते हैं कि यह एक महीने पहले तैयार हो जाना चाहिए था।

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


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

लेकिन दार्शनिक होने के लिए, आइए कुछ अधिक या कम विशिष्ट उदाहरण देखें।

दक्षता और रखरखाव

मुझे लगता है कि सबसे आम समझौता है कि ज्यादातर डेवलपर्स का सामना समाधान की दक्षता (उत्पादकता) और इसकी स्थिरता के बीच समझौता है।

आइए ऐसे एक उदाहरण को देखें।

internal class SomeType { private readonly int _i = 42; private readonly string _s = "42"; private readonly double _d; public SomeType() { } public SomeType(double d) { _d = d; } } 

यह एक बहुत ही विशिष्ट उदाहरण है जहां कुछ वर्ग में डिफ़ॉल्ट मान होते हैं जो किसी क्षेत्र के घोषित होने पर आरंभिक होते हैं। हालाँकि, यह उदाहरण कुछ कोड सूजन की ओर जाता है, क्योंकि C # भाषा संकलक इसे कुछ इस तरह से परिवर्तित करता है:

 public SomeType() { _i = 42; _s = "42"; // System.Object::ctor(); } public SomeType(double d) { _i = 42; _s = "42"; // System.Object::ctor(); _d = d; } 

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

जेफरी रिक्टर अपनी अद्भुत पुस्तक "सीएलआर विद सी #" में निम्नलिखित सलाह देते हैं: क्योंकि घोषणा के दौरान फ़ील्ड इनिशियलाइज़ेशन के कारण कोड सूजन हो सकती है, आपको एक अलग कंस्ट्रक्टर को आवंटित करने पर विचार करना चाहिए जो सभी बुनियादी आरंभीकरण करता है और स्पष्ट रूप से अन्य कंस्ट्रक्टरों से कॉल करता है।

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

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

सुरक्षा और प्रभावकारिता

कुछ समाधानों के डिजाइन में एक और बहुत ही सामान्य समझौता एक संरचना और एक वर्ग (एक महत्वपूर्ण प्रकार और एक संदर्भ प्रकार के बीच) के बीच का विकल्प है। एक ओर, एक निश्चित आकार (x86 प्लेटफ़ॉर्म पर 24 बाइट्स के आदेश) तक संरचना प्रबंधित ढेर में मेमोरी आवंटन की कमी के कारण प्रदर्शन में काफी सुधार कर सकती है। लेकिन दूसरी ओर, उत्परिवर्तनीय महत्वपूर्ण प्रकारों के मामले में, हम बहुत ही गैर-तुच्छ समस्याओं को प्राप्त कर सकते हैं, क्योंकि व्यवहार वही हो सकता है जो कई डेवलपर्स सुझाव देते हैं।

नोट
कई लोग परस्पर महत्वपूर्ण प्रकारों को हमारे समय की सबसे बड़ी बुराई मानते हैं। यदि आप यह नहीं समझते हैं कि इसके बारे में क्या है या बस इस राय से सहमत नहीं हैं, तो आपको "परस्पर महत्वपूर्ण प्रकार के खतरों पर" लेख को देखना चाहिए, शायद उसके बाद, आपकी राय बदल जाएगी;)

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

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

 var x = new { Items = new List<int> { 1, 2, 3 }.GetEnumerator() }; while (x.Items.MoveNext()) { Console.WriteLine(x.Items.Current); } 

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

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

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

सरलता बनाम बहुमुखी प्रतिभा

जब यह उच्च स्तर के डिजाइन की बात आती है, तो इस तरह की पसंद की समस्या अक्सर उत्पन्न होती है: हमारा समाधान कितना सार्वभौमिक होना चाहिए, या क्या यह एक विशिष्ट कार्य के लिए खुद को सीमित करने के लिए पर्याप्त है, और केवल तब एक सामान्यीकृत समाधान पर आगे बढ़ना चाहिए?

कई प्रोग्रामर और आर्किटेक्ट सहज रूप से मानते हैं कि बदलती आवश्यकताओं से निपटने के लिए सार्वभौमिकता सबसे अच्छा तरीका है। यदि आज ग्राहक को केवल टूथपिक की आवश्यकता है, तो चलो तुरंत एक टूथपिक के कार्य के साथ स्विस चाकू बनाते हैं, बस मामले में, और अचानक आवश्यकताएं बदल जाती हैं!

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

जब यह इस तरह की पसंद की बात आती है, और हम तय करते हैं कि शुरू से ही "स्विस चाकू" बनाना है या नहीं, तो मैं कुछ समझौता समाधान के लिए इच्छुक हूं। जैसा कि मैंने पहले ही पुन: उपयोग पर नोट में लिखा था, इस समस्या का सबसे प्रभावी समाधान शुरू से ही एक सरल समाधान है, जो कि आवश्यक होने पर, बाद के पुनरावृत्तियों में से एक के लिए सामान्यीकृत है।

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

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

पुस्तकालय और उपयोगिता

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

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

लाइब्रेरी डेवलपर OOP के सभी सिद्धांतों पर स्कोर कर सकते हैं यदि वे पुस्तकालय के मुख्य सिद्धांत का विरोध करते हैं - उपयोग की सादगी और गहनता। एक पुस्तकालय को बनाए रखना बहुत मुश्किल हो सकता है, क्योंकि इसमें जोड़ा गया हर समाधान कभी भी (या लगभग कभी नहीं) बदला जा सकता है।

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

जब हम एप्लिकेशन एप्लिकेशन से पुस्तकालयों में जाते हैं, तो ऊपर वर्णित सभी समझौतों के समाधान नाटकीय रूप से भिन्न होते हैं। माइक्रोएप्टिमाइजेशन, एक्स्टेंसिबिलिटी, डर्टी हैक्स, "ब्रेकिंग चेंजेस" की समस्या, कंसिस्टेंसी (यहां तक ​​कि कई अन्य महत्वपूर्ण कारकों की गिरावट तक), यह सब लगातार पुस्तकालयों में पाया जाता है। इसीलिए, जब सॉफ़्टवेयर विकास से संबंधित अधिकांश युक्तियों की बात आती है, तो आपको स्पष्ट रूप से समझने की आवश्यकता है कि यह विशेष पुस्तकालयों के बजाय, अनुप्रयोग विकास पर लागू होने की सबसे अधिक संभावना है।

निष्कर्ष

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

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

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