.NET में लिंकर के कार्यान्वयन में सुधार कैसे करें

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

नीचे मैं C # की क्षमताओं के संबंध में, इस समस्या के अपने समाधान का प्रस्ताव दूंगा।


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



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

अब आइए IComponent इंटरफ़ेस के कार्यान्वयन को निर्धारित करने का प्रयास करें, जो संभावित परिवर्तनों के लिए अच्छी तरह से अनुकूलित होगा, और इसलिए विभिन्न पदानुक्रमों के निर्माण के लिए लागू होगा।

using System.Collections.Generic;
using System.Diagnostics.Contracts;
namespace ComponentLibrary
{
[ContractClass( typeof (IComponentContract))]
public interface IComponent< out TComponent, out TChildrenCollection>
where TComponent : IComponent<TComponent, TChildrenCollection>
where TChildrenCollection : class , IEnumerable <TComponent>
{
TChildrenCollection Children { get ; }
bool IsComposite { get ; }
}
}

* This source code was highlighted with Source Code Highlighter .

इंटरफ़ेस को टेम्पलेट इंटरफ़ेस के रूप में क्यों लागू किया गया है और यह किस प्रकार के मापदंडों को स्वीकार करता है? वास्तव में, यह विचार बहुत सरल है: जहां वास्तविक प्रकार अभी तक ज्ञात नहीं हैं, वहां मजबूत टाइपिंग लाएं।

TComponent उस चाइल्ड इंटरफ़ेस का वास्तविक प्रकार है (या अधिक बारीकी से संबंधित आर्किटेक्चर में कक्षा) जिसे आप ऑपरेशन (जैसे) में जिम्मेदारियों को जोड़ने के लिए IComponent से विरासत में प्राप्त करेंगे।

TChildrenCollection संग्रह इंटरफ़ेस है जिसे आप बच्चों को संदर्भित करने के लिए कार्यान्वित करते हैं। इस इंटरफ़ेस में कम से कम केवल GetEnumerator () को परिभाषित किया जाना चाहिए, जिसके माध्यम से आप संग्रह सूचना प्राप्त कर सकते हैं। तथ्य यह है कि कभी-कभी ऐड () और निकालें () जैसे तरीकों को प्रदान करना आवश्यक नहीं है, क्योंकि सभी तत्वों को कंस्ट्रक्टर में जोड़ा जा सकता है, और पदानुक्रमित संरचना को स्वयं निर्माण के बाद नहीं बदला जाना चाहिए। और अगर आपको अचानक एक संग्रह परिवर्तन के बारे में सूचनाओं की आवश्यकता है - एक पर्यवेक्षक को पारित करें <TComponent> एक TChildrenCollection के रूप में, और यह सब टोपी के बारे में है!

प्रकार के अनुबंध में, हम बच्चों की संपत्ति के वापसी मूल्य पर निम्नलिखित प्रतिबंधों को निर्दिष्ट करते हैं: 1) लौटा संग्रह शून्य नहीं है; 2) इसका कोई भी तत्व अशक्त नहीं है; 3) घटक या तो समग्र के रूप में निर्दिष्ट है या इसमें बाल तत्व नहीं हैं। संक्षिप्तता के लिए, अनुबंध कोड यहां नहीं दिया गया है।

याद रखें, हमने कहा था कि हम प्रत्येक घटक को एक अतिरिक्त विधि देना चाहेंगे जो एक पुनरावृति देता है जो जटिल सबट्री ट्रैवर्सल लॉजिक को लागू करता है? मान लीजिए कि हमने ऐसा इटरेटर लिखा है, ComponentDescendantsEnumerator <TComponent> (इसका कोड लेख के अंत में लिंक से डाउनलोड किया जा सकता है), और फिर इसे क्लास ComponentDescendantsEnumerable <TComponent> में लपेट दिया, जो IEnumerable <TComponent> को परिभाषित करता है। अब आपको यह तय करने की आवश्यकता है कि समान पुनरावृत्तियों को वापस करने के तरीके कहाँ रखें? सौभाग्य से, सी # में एक बहुत ही उपयोगी तंत्र है - विस्तार के तरीके। आइए इसे लागू करने का प्रयास करें।

namespace ComponentLibrary.Extensions
{
public static class ComponentExtensions
{
public static IEnumerable <T> GetDescendants<T>( this T component)
where T : IComponent<T, IEnumerable <T>>
{
//
return new ComponentDescendantsEnumerable<T>(component);
}
}
}

* This source code was highlighted with Source Code Highlighter .

हम एक्सटेंशन विधि को एक अलग नामस्थान में लागू करते हैं - इस तरह से हम इसे IComponent <,> इंटरफ़ेस से संबंधित विधि की तरह कह सकते हैं, जब हम इस नाम स्थान को आयात करते हैं।

अगला, हमारे पास एक और कार्य है: हमें उन संग्रह को पुनर्प्राप्त करने के लिए एक विधि को लागू करने की आवश्यकता है जिसमें कभी भी तत्व शामिल न हों, और सभी परिवर्तन अनुरोधों (जैसे जोड़ें / निकालें) पर NotSupportedException को फेंक दें। सबसे पहले, एक ऐसा संग्रह बनाएं जो ICollection <T> को लागू करता है। हालांकि, यदि कोई संग्रह कभी नहीं बदलता है और हमेशा खाली होता है, तो पूरे कार्यक्रम के लिए (या बल्कि, AppDomain पर) इस तरह के एक से अधिक संग्रह करने का कोई मतलब नहीं है। सिंगलटन पैटर्न का लाभ लेने के लिए एक आदर्श मामला! (सिंग्लटन <टी> वर्ग का कार्यान्वयन संलग्न स्रोतों में पाया जा सकता है)

sealed internal class ItemsNotSupportedCollection<T> :
Singleton<ItemsNotSupportedCollection<T>>,
ICollection<T>
{
private ItemsNotSupportedCollection() { }

public int Count { get { return 0; } }

public bool IsReadOnly { get { return true ; } }

public bool Contains(T item) { return false ; }

public void CopyTo(T[] array, int arrayIndex) { }

public void Add(T item) { throw new NotSupportedException(); }

public void Clear() { throw new NotSupportedException(); }

public bool Remove(T item) { throw new NotSupportedException(); }

public IEnumerator<T> GetEnumerator()
{
return ItemsNotSupportedEnumerator<T>.Instance;
}

IEnumerator IEnumerable .GetEnumerator()
{ return this .GetEnumerator(); }
}

* This source code was highlighted with Source Code Highlighter .

पारदर्शिता के लिए, प्रयुक्त पुनरावृत्ति वर्ग एक खाली संग्रह के पुनरावृत्ति का प्रतिनिधित्व करता है, इसलिए, इसका एक उदाहरण भी पर्याप्त है - फिर से एक सिंगलटन।

sealed internal class ItemsNotSupportedEnumerator<T> :
Singleton<ItemsNotSupportedEnumerator<T>>,
IEnumerator<T>
{
private ItemsNotSupportedEnumerator() { }

public T Current { get { return default (T); } }

public void Dispose() { }

object IEnumerator.Current { get { return null ; } }

public bool MoveNext() { return false ; }

public void Reset() { throw new NotSupportedException(); }
}

* This source code was highlighted with Source Code Highlighter .

यह केवल एक स्थिर संपत्ति बनाने के लिए बनी हुई है जो असेंबली के बाहर से दिखाई देती है और ICollection <T> इंटरफ़ेस के लिए तत्वों का केवल-पठन संग्रह लौटाती है।

public static class ComponentCollections<TComponent>
where TComponent : IComponent<TComponent, IEnumerable <TComponent>>
{
public static ICollection<TComponent> EmptyCollection
{
get
{
//
return ItemsNotSupportedCollection<TComponent>.Instance;
}
}
}

* This source code was highlighted with Source Code Highlighter .

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



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

namespace MenuLibrary
{
public interface IMenuItem :
IComponent<IMenuItem, ICollection<IMenuItem>>
{
string Name { get ; }
void Display( int indent = 0);
}
}

* This source code was highlighted with Source Code Highlighter .

एक TComponent प्रकार के पैरामीटर के रूप में, हम हमेशा घटक इंटरफ़ेस (अर्थात, समान IMenuItem) पास करते हैं, TChildrenCollection, कार्यान्वित संग्रह के इंटरफ़ेस के रूप में। हम TChildrenCollection के लिए अपने स्वयं के इंटरफ़ेस को जोड़ सकते हैं, जो कि पैटर्न को जोड़ने के रूप में Add, Remove, और GetChild तरीके (साथ ही GetEnumerator) को परिभाषित करता है। उदाहरण के लिए IList <IMenuItem> पास करना संभव है, लेकिन हमने तय किया कि यहां मानक इंटरफ़ेस ICollection <IMenuItem> हमें सूट करता है।

यह है कि हम MenuCommand पत्ती घटक को कैसे परिभाषित करते हैं:

public class MenuCommand : IMenuItem
{
private readonly string name;

public MenuCommand( string name)
{
//
this .name = name;
}

public string Name { get { return this .name; } }

public void Display( int indent = 0)
{
string indentString = MenuHelper.GetIndentString(indent);
Console .WriteLine( "{1}{0} [Command]" , this .name, indentString);
}

public ICollection<IMenuItem> Children
{
get { return ComponentCollections<IMenuItem>.EmptyCollection; }
}

public bool IsComposite { get { return false ; } }
}

* This source code was highlighted with Source Code Highlighter .

बच्चों की संपत्ति पत्ती तत्वों के लिए पहले से घोषित "सिंगलटन" संग्रह लौटाती है। अब कंपोजिट कंपोनेंट मेन्यू घोषित करें।

public class Menu : IMenuItem
{
private readonly ICollection<IMenuItem> children =
new List <IMenuItem>();

private readonly string name;

public Menu( string name)
{
//
this .name = name;
}

public string Name { get { return this .name; } }

public void Display( int indent = 0)
{
string indentString = MenuHelper.GetIndentString(indent);
Console .WriteLine( "{1}{0} [Menu]" , this .name, indentString);
int childrenIndent = indent + 1;
foreach (IMenuItem child in this .children)
{
child.Display(childrenIndent);
}
}

public ICollection<IMenuItem> Children
{ get { return this .children; } }

public bool IsComposite { get { return true ; } }
}

* This source code was highlighted with Source Code Highlighter .

बच्चे अप्रत्याशित रूप से प्रयुक्त मानक सूची <T> संग्रह लौटाते हैं। यह एक अच्छा कदम है अगर हमारे पदानुक्रम के उपयोगकर्ता को सूची <T> के लिए बच्चों के प्रकार के ऑब्जेक्ट को डालने और इस वर्ग की सभी अतिरिक्त विशेषताओं का उपयोग करने की अनुमति है। लेकिन अगर ऐसा लेआउट अस्वीकार्य है, तो आपको एक निश्चित आंतरिक वर्ग में सूची <T> को लपेटने की आवश्यकता है जो केवल ICollection <T> को लागू करता है और अन्य विधानसभाओं (या यहां तक ​​कि कक्षाओं) के लिए दुर्गम है।

अब हमारे द्वारा लिखे गए कोड का परीक्षण करें।

using System;
using System.Linq;
using ComponentLibrary.Extensions;
using MenuLibrary;
namespace MenuTest
{
public static class MenuTest
{
public static void Perform()
{
//
IMenuItem rootMenu = new Menu( "Root" );
// ... File
IMenuItem fileMenu = new Menu( "File" );
fileMenu.Children.Add( new MenuCommand( "New" ));
fileMenu.Children.Add( new MenuCommand( "Open" ));
// ... File->Export
IMenuItem fileExportMenu = new Menu( "Export" );
fileExportMenu.Children.Add( new MenuCommand( "Text Document" ));
fileExportMenu.Children.Add( new MenuCommand( "Binary Format" ));
fileMenu.Children.Add(fileExportMenu);
// ... File
fileMenu.Children.Add( new MenuCommand( "Exit" ));
rootMenu.Children.Add(fileMenu);
// ... Edit
IMenuItem editMenu = new Menu( "Edit" );
editMenu.Children.Add( new MenuCommand( "Cut" ));
editMenu.Children.Add( new MenuCommand( "Copy" ));
editMenu.Children.Add( new MenuCommand( "Paste" ));
rootMenu.Children.Add(editMenu);
//
rootMenu.Display();
Console .WriteLine();
// ,
// Root, "E" "R"
var compositeMenuNames =
from menu in rootMenu.GetDescendants()
where menu.IsComposite
&& (menu.Name.StartsWith( "E" ) || menu.Name.StartsWith( "R" ))
select menu.Name;
foreach ( string menuName in compositeMenuNames)
{
Console .WriteLine(menuName);
}
}
}
}

* This source code was highlighted with Source Code Highlighter .

GetDescendants () एक्सटेंशन विधि द्वारा लौटी गणना के लिए LINQ क्वेरी पर ध्यान दें। काम के परिणाम पर एक नज़र डालें।



इतना सरल। इसके अलावा, विकसित घटकों के तर्क में, सभी डिजाइनर का ध्यान व्यावसायिक तर्क के निर्माण पर केंद्रित है, न कि एक श्रेणीबद्ध संरचना या कंटेनर कक्षाओं पर।

सूत्रों का लिंक: http://www.fileden.com/files/2011/10/7/3205975/ComponentLibrary.zip

PS यदि आपको कुछ स्पष्ट नहीं लग रहा था, या आप केवल पढ़ने के लिए पदानुक्रम के कार्यान्वयन विकल्प को देखना चाहते हैं, तो आप उसी पोस्ट के विस्तारित संस्करण का उल्लेख कर सकते हैं।

पीपीएस ईमानदार होने के लिए, मुझे उम्मीद है कि टिप्पणियों में कोई मेरे साथ लिंकर कार्यान्वयन के बेहतर संस्करण का सुझाव देगा।

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

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