विस्तार के तरीके: पागलपन बंद करो!

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

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

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

आइए एक प्राथमिक उदाहरण को देखें, बस यह याद रखने के लिए कि ओओपी क्या है (अर्थात्, इसका एक पहलू एनकैप्सुलेशन है )।

public class Cat { public float CuddlynessFactor { get; private set; } public Cat(float cuddlynessFactor) { this.CuddlynessFactor = cuddlynessFactor; } public void Purr() { Console.WriteLine("Purr!"); } public void HitTheWall() { Console.WriteLine("Fu**ing meow!!!"); } } public class Dog { public float TeethSharpness { get; private set; }; public Dog(float teethSharpness) { this.TeethSharpness = teethSharpness; } public void Bark() { Console.WriteLine("Bark!"); } public void Bite(Human target) { target.Leg.DoDamage(DamageLevel.Substantial); } } 

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

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

 public static class Transmogrificator { public static Cat DogToCat(Dog dog) { return new Cat(Math.Sqrt(dog.TeethSharpness) * 42); } } 

देखा! नई कक्षा का उपयोग करके, हम आसानी से एक कुत्ते को एक बिल्ली में बदल सकते हैं!

 public void Test() { var uberDog = new Dog(float.Infinity); var testHuman = new Human(); uberDog.Bark(); uberDog.Bite(testHuman); var cat = Transmogrificator.DogToCat(dog); cat.HitTheWall(); } 

मिठाई! और अब हम विस्तार विधियों की अवधारणा से संपर्क कर रहे हैं, जिसे Microsoft ने हाल ही में .NET में पेश किया है। जैसा कि लेखकों द्वारा कल्पना की गई है, एक्सटेंशन विधियों को लागू किया जाना चाहिए जहां लक्ष्य वर्ग के पास कोई कार्यक्षमता नहीं है जो इसे स्पष्ट रूप से चाहिए (या, कम से कम, इसका हिस्सा हो सकता है)। विस्तार विधियों में यह बताया गया है। और वाई। MSDN:

सामान्य तौर पर, आप शायद अपने खुद के कार्यान्वयन की तुलना में अधिक बार विस्तार विधियों को बुलाएंगे।
[...]
सामान्य तौर पर, हम अनुशंसा करते हैं कि आप विस्तार विधियों को संयम से लागू करें और केवल जब आपको करना हो। जब भी संभव हो, एक मौजूदा प्रकार का विस्तार करने वाले ग्राहक कोड को मौजूदा प्रकार से प्राप्त एक नया प्रकार बनाकर ऐसा करना चाहिए।
[...]
एक एक्सटेंशन विधि का उपयोग करते समय एक प्रकार जिसका स्रोत कोड आप नहीं बदल सकते हैं, आप जोखिम चलाते हैं कि प्रकार के कार्यान्वयन में परिवर्तन से आपकी एक्सटेंशन विधि टूट जाएगी।

सीधे शब्दों में कहें, तो लेखक हमें विस्तार विधियों का उपयोग करने की सलाह देते हैं, जब यह वास्तव में आवश्यक हो ।

अब देखते हैं कि क्या होता है अगर हम डॉगटोकैट विधि को एक विस्तार विधि बनाकर अपने उदाहरण को संशोधित करते हैं।

 public void Test() { var uberDog = new Dog(float.Infinity); var testHuman = new Human(); uberDog.Bark(); uberDog.Bite(testHuman); var cat = dog.DogToCat(); cat.HitTheWall(); } 

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

• ओओपी के मूल सिद्धांतों में से एक का उल्लंघन किया जाता है - इनकैप्सुलेशन। बिल्ली बनने की क्षमता एक कुत्ते के स्वामित्व वाली क्षमता नहीं है। यह चेनसॉ के साथ अच्छे डॉक्टर की क्षमता है और खून से सना हुआ एक बागे है। विस्तार के तरीकों के लिए मनोवैज्ञानिक कहेंगे कि एनकैप्सुलेशन औपचारिक रूप से टूटा नहीं है, क्योंकि विधि का कार्यान्वयन अभी भी एक स्थिर वर्ग में है। हालांकि, अपने आप को एक नए डेवलपर के स्थान पर कल्पना करें जो किसी और के कोड को समझता है। यह निष्कर्ष निकालना उनके लिए पूरी तरह से तर्कसंगत होगा कि डॉगटोकैट पद्धति बिल्कुल कुत्ते के प्रकार की है! बस हताशा की कड़वाहट की कल्पना करें जो वह अनुभव करेगी जब उसे पता चलेगा कि यह वास्तव में एक विस्तार विधि है। क्या आपने कभी धोखा महसूस किया है? शायद गरीब साथी को एक मनोचिकित्सक की सेवाओं की भी आवश्यकता होगी।
• यह स्पष्ट नहीं है कि विभिन्न विस्तार विधियां एक ही वर्ग के लिए कहां हैं। यह स्पष्ट नहीं है कि उन्हें कैसे जोड़ा जाए। एक स्थिर वर्ग का उपयोग करते समय, हमारे पास एक सुव्यवस्थित नाम है जो आमतौर पर इस वर्ग के तर्क को दर्शाता है, विस्तार के तरीकों के लिए हमारे पास केवल अनुमान हैं। वांछित विधि को जोड़ने के लिए, हमें एक नामस्थान पंजीकृत करने की आवश्यकता है, जिसका नाम पूरी तरह से स्पष्ट हो सकता है। हां, मैं आपको R # प्रशंसक सुनता हूं। मैं खुद इस उपकरण से वास्तव में प्यार करता हूं, लेकिन इस मामले में यह केवल एक संवेदनाहारी है जो गैंग्रीन से प्रभावित पैर में दर्द का सामना करता है। केज विस्तार के तरीकों को जोड़ने की प्रारंभिक गैर-स्पष्टता हमें संकेत देती है, लेकिन हम मन के तर्कों को नहीं सुनना पसंद करते हैं और इसके बजाय खुद को मोर्फिन की एक और खुराक के साथ फेंक देते हैं।

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

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