🚒 👇🏾 👨‍🎨 .NET और डिजाइन पैटर्न 🍄 🍣 🤸🏿

एक डिजाइन पैटर्न या पैटर्न एक दोहराए जाने वाला वास्तुशिल्प डिजाइन है जो एक संदर्भ के भीतर एक डिजाइन समस्या का समाधान है जो अक्सर उत्पन्न होता है।

ऐसा लगता है कि हमने इस परिभाषा को एक हजार बार सुना है ... शब्दों और पैटर्न को जानने के अलावा, यह जानना दिलचस्प है कि उनका वास्तविक परियोजनाओं में कैसे उपयोग किया जाता है।

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

एक दर्जन से अधिक पुस्तकें डिजाइन पैटर्न के लिए समर्पित हैं, लेकिन एक पुस्तक अलग है और यह प्रसिद्ध पुस्तक "गैंग्स ऑफ फोर" है। इसलिए, स्थिति की बेहतर समझ के लिए, मैं इस पुस्तक से एक संक्षिप्त विवरण प्रदान करूंगा।

हम निम्नलिखित छह पैटर्न को कवर करेंगे:

पर्यवेक्षक;
इटरेटर;
डेकोरेटर;
एडाप्टर;
कारखाने;
रणनीति।

तो चलो शुरू करते हैं।

प्रेक्षक

शायद .NET में प्रयुक्त सबसे प्रसिद्ध पैटर्न पर्यवेक्षक है। यह ज्ञात है क्योंकि यह प्रतिनिधियों की नींव है, जो अपनी स्थापना के बाद से .NET का अभिन्न अंग रहे हैं। .NET ऑब्जेक्ट मॉडल में उनके योगदान की सराहना नहीं करना, विशेष रूप से यह विचार करना कि वे बाद के संस्करणों (लैम्ब्डा, क्लोज़र, आदि) में क्या-क्या देखते हैं।

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

C # में इस पैटर्न का सबसे सरल कार्यान्वयन कुछ इस तरह दिख सकता है:

सरल प्रेक्षक

public interface IObserver //   { void Notify(); } public abstract class Subject //  { private List<IObserver> observers = new List<IObserver>(); public void Add(IObserver o) { observers.Add(o); } public void Remove(IObserver o) { observers.Remove(o); } public void Notify() //    { foreach (IObserver o in observers) o.Notify(); } }

जैसा कि मैंने .NET प्लेटफ़ॉर्म में कहा है, प्रतिनिधियों द्वारा पर्यवेक्षक अमूर्तता को लागू किया जाता है। प्रतिनिधियों के साथ अधिक सुविधाजनक काम के लिए, घटनाओं का उपयोग C # में किया जाता है। निम्नलिखित उदाहरण में, हम उनका उपयोग करेंगे:

.NET में ऑब्जर्वर

 public delegate void MyEventHandler(); //    public class Subject { public Subject() { } public MyEventHandler MyEvent; //  public void RaiseEvent() //       { MyEventHandler ev = MyEvent; if (ev != null) ev(); } } static void Main(string[] args) { Subject s = new Subject(); s.MyEvent += () => Console.WriteLine("Hello habrahabr"); //   s.MyEvent += () => Console.WriteLine("Hello world"); //   s.RaiseEvent(); //    Console.ReadKey(); }

चेहरे पर पर्यवेक्षक पैटर्न के साथ एक समानता। एक घटना एक विषय के रूप में कार्य करती है, जबकि पर्यवेक्षकों के रूप में प्रतिनिधि।

टिप्पणी

ऊपर वर्णित कोड में एक खामी है: लैम्ब्डा एक्सप्रेशन का उपयोग करते समय, प्रतिनिधि को डिस्कनेक्ट करना संभव नहीं होगा, अर्थात कोड

 s.MyEvent -= () => Console.WriteLine("Hello habrahabr");

यह प्रतिनिधि नहीं हटाएगा, क्योंकि यह एक अलग उदाहरण है। प्रतिनिधि को अलग करने के लिए, आपको एक चर में प्रतिनिधि (भेड़ का बच्चा अभिव्यक्ति) को बचाना होगा।

 static void Main(string[] args) { Subject s = new Subject(); MyEventHandler myEv1 = () => Console.WriteLine("Hello habarhabr"); MyEventHandler myEv2 = () => Console.WriteLine("Hello world"); s.MyEvent += myEv1; s.MyEvent += myEv2; s.MyEvent -= myEv1; s.RaiseEvent(); //      Console.ReadKey(); }

.NET 4.0 ने पर्यवेक्षक पैटर्न को सीधे लागू करने के लिए इंटरफेस शुरू किया। वे इस तरह दिखते हैं:

 public interface IObservable<out T> { IDisposable Subscribe(IObserver<T> observer); } public interface IObserver<in T> { void OnCompleted(); void OnError(Exception error); void OnNext(T value); }

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

टिप्पणी

इटरेटर

.NET में उपयोग के लिए कोई कम लोकप्रिय अगला पैटर्न एक पुनरावृत्त नहीं है।

GOF से पुनरावृत्त पैटर्न का उद्देश्य: एक समग्र वस्तु के सभी तत्वों को उसके आंतरिक प्रतिनिधित्व को प्रकट किए बिना अनुक्रमिक पहुंच का एक तरीका प्रदान करता है।

.NET प्लेटफ़ॉर्म पर, इट्रेटर पैटर्न को लागू करने के लिए दो इंटरफेस जिम्मेदार हैं: IEnumerable और IEnumerator

 public interface IEnumerable { IEnumerator GetEnumerator(); } public interface IEnumerator { object Current { get; } bool MoveNext(); void Reset(); }

साथ ही उनके सामान्यीकृत एनालॉग्स:

 public interface IEnumerable<out T> : IEnumerable { IEnumerator<T> GetEnumerator(); } public interface IEnumerator<out T> : IDisposable, IEnumerator { T Current { get; } }

फ़ॉरच लूप का उपयोग करके कुछ इकाई को पुनरावृत्त करने में सक्षम होने के लिए, इसमें IEnumerable <> इंटरफ़ेस को लागू करना आवश्यक है, साथ ही साथ इट्रेटर को भी बनाना है - एक वर्ग / संरचना जो IEnumerator <इंटरफ़ेस को लागू करता है।

यह ध्यान में रखते हुए कि इट्रियर ब्लॉक सी # 2.0 में उपज कीवर्ड का उपयोग करते हुए दिखाई देता है, IEnumerator <> इंटरफ़ेस को लागू करने वाले कस्टम प्रकार अब शायद ही कभी होता है (कंपाइलर हमारे लिए ऐसा करता है)।

फ़ॉर्चर पैटर्न के साथ अगल-बगल का लूप कंधे से कंधा मिलाकर काम करता है। निम्नलिखित कोड

 foreach (var item in Enumerable.Range(0, 10)) { Console.WriteLine(item); }

यह कोड के लिए सिंटैक्टिक शुगर है:

 IEnumerator<int> enumerator = Enumerable.Range(0, 10).GetEnumerator(); try { while (enumerator.MoveNext()) { int item = enumerator.Current; Console.WriteLine(item); } } finally { if (enumerator != null) { enumerator.Dispose(); } }

इस प्रकार, इट्रेटर पैटर्न C # भाषा का आधार है, क्योंकि इसका भाषा निर्माण (फ़ॉरचेक) इसका उपयोग करता है।

टिप्पणी

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

फ़ॉरेस्ट लूप के संबंध में .NET में कई अनुकूलन हैं। चूंकि प्रत्येक पुनरावृत्ति पर एक इटेरेटर ऑब्जेक्ट बनाया जाता है, इसलिए यह कचरा संग्रह को नकारात्मक रूप से प्रभावित कर सकता है, खासकर अगर कई फ़ॉरच लूप हैं, इसलिए जब एरे और स्ट्रिंग्स (सीएलआर में गहन रूप से एकीकृत) को पुनरावृत्त करते हैं, तो फ़ॉरच लूप लूप के लिए एक नियमित रूप से सामने आता है।

टिप्पणी

डेकोरेटर

पैटर्न नंबर 3 - वस्तुओं का डेकोरेटर।

GOF से पैटर्न डेकोरेटर का उद्देश्य: गतिशील रूप से ऑब्जेक्ट में नई जिम्मेदारियों को जोड़ता है। यह कार्यक्षमता का विस्तार करने के लिए उपवर्ग का एक लचीला विकल्प है।

.NET में डेकोरेटर को System.IO.Stream क्लास और उसके वंशजों द्वारा दर्शाया गया है। निम्नलिखित कोड पर विचार करें:

 public static void WriteBytes(Stream stream) { int oneByte; while ((oneByte = stream.ReadByte()) >= 0) { Console.WriteLine(oneByte); } } static void Main(string[] args) { var memStream = new MemoryStream(new byte[] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }); WriteBytes(memStream); var buffStream = new BufferedStream(memStream); WriteBytes(buffStream); Console.ReadLine(); }

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

System.Security.Cryptography.CryptoStream क्लास आपको फ्लाई पर एन्क्रिप्ट और डिक्रिप्ट स्ट्रीम की अनुमति देता है। यह कंस्ट्रक्टर में टाइप स्ट्रीम के एक पैरामीटर को भी स्वीकार करता है, इसे अपने शेल में लपेटता है।

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

अनुकूलक

GOF से अडैप्टर पैटर्न का उद्देश्य: एक वर्ग के इंटरफेस को दूसरे के इंटरफेस में परिवर्तित करता है, जो ग्राहक उम्मीद करते हैं। एडेप्टर कक्षाओं को असंगत इंटरफेस के साथ काम करने की अनुमति देता है, जो इसके बिना संभव नहीं होता।

COM और .NET में एक अलग आंतरिक वास्तुकला है। इसलिए, एक इंटरफ़ेस को दूसरे में बदलना आवश्यक है। CLR COM ऑब्जेक्ट को रन-टाइम नामक एक मध्यस्थ के माध्यम से शेल (RCW) तक पहुंच प्रदान करता है।

रनटाइम प्रत्येक COM ऑब्जेक्ट के लिए रनटाइम रैपर बनाता है, भले ही इस ऑब्जेक्ट के मौजूदा संदर्भों की संख्या हो।

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

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

वास्तव में, आरसीडब्ल्यू एक एडाप्टर है जो एक इंटरफ़ेस को दूसरे में परिवर्तित करता है।

कारखाना है

पांचवा पैटर्न एक तरह का कारखाना है।

GOF से फैक्ट्री पैटर्न का उद्देश्य: विशिष्ट वर्गों को निर्दिष्ट किए बिना परस्पर या अन्योन्याश्रित वस्तुओं के परिवारों को बनाने के लिए एक इंटरफ़ेस प्रदान करता है।

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

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

Activator.CreateInstance प्रकार की जानकारी के साथ संयोजन विधि एक अमूर्त वर्ग कारखाने को लागू करती है, अर्थात। वह जो किसी भी प्रकार के उदाहरण बना सकता है।

रणनीति

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

इस सरल पैटर्न को लागू करने का एक अच्छा उदाहरण सरणियों को छांटना है। Array.Sort विधि के अधिभार में से एक, IComparable के प्रकार का एक पैरामीटर लेता है। इस इंटरफ़ेस का उपयोग करके, हम तथाकथित रणनीतियों के लिए एक-दूसरे से स्वतंत्र होने वाले एल्गोरिदम को सॉर्ट करने की एक श्रृंखला बना सकते हैं और यह आसानी से विनिमेय हैं।

 public interface IComparable<T> { int CompareTo(T other); }

सॉर्ट कोड वस्तुतः तत्व तुलना एल्गोरिदम से स्वतंत्र है और अपरिवर्तित रह सकता है।

इसमें Array.BinarySearch विधियाँ भी शामिल हैं, जो IComparable इंटरफ़ेस और Array.Find विधि को भी स्वीकार करती है, जिसे Prateate प्रतिनिधि स्वीकार करता है। इस प्रकार, विभिन्न प्रतिनिधियों (रणनीतियों) को अलग करके, हम विधि के व्यवहार को बदल सकते हैं और हमें आवश्यक परिणाम प्राप्त कर सकते हैं।

सामान्य तौर पर, रणनीति पैटर्न का उपयोग हर समय किया जाता है। इस लेख को लिखने से पहले, मैंने वास्तव में नहीं सोचा था कि मैं अलग पैटर्न की तुलना में सरणियों को छांटते समय रणनीति पैटर्न का उपयोग करता हूं।

निष्कर्ष

अब जब हमने .NET फ्रेमवर्क में उपयोग किए गए कुछ पैटर्नों को देखा है, तो मुझे लगता है कि आपके लिए उन्हें उस कोड में पहचानना और भी आसान होना चाहिए, जिस कोड में आप काम कर रहे हैं। सामान्य रूप से C # भाषा और .NET बुनियादी ढांचे में घटनाओं और पुनरावृत्तियों के योगदान की सराहना नहीं करना मुश्किल है, इसलिए यह जानना कि यह क्लासिक डिजाइन पैटर्न का कार्यान्वयन है बस आवश्यक है।

पढ़ने के लिए धन्यवाद। मुझे उम्मीद है कि यह लेख मददगार रहा है।

.NET और डिजाइन पैटर्न