क्या संग्रह में आइटम जोड़ने के अधिक "प्राकृतिक" तरीके के लिए एक पैटर्न है? [बन्द है]


13

मुझे लगता है कि किसी संग्रह में किसी चीज़ को जोड़ने का सबसे आम तरीका है Addकि किसी तरह की विधि का उपयोग करना जो एक संग्रह प्रदान करता है:

class Item {}    
var items = new List<Item>();
items.Add(new Item());

और वास्तव में इसके बारे में कुछ भी असामान्य नहीं है।

मुझे आश्चर्य है कि हम ऐसा क्यों नहीं करते हैं:

var item = new Item();
item.AddTo(items);

यह किसी भी तरह अधिक प्राकृतिक लगता है तो पहली विधि है। यह andvtange होगा कि जब Itemवर्ग की तरह एक संपत्ति है Parent:

class Item 
{
    public object Parent { get; private set; }
} 

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

लेकिन शायद मैं गलत हूं और मैंने इस पैटर्न को पहले कभी नहीं देखा है क्योंकि यह बहुत असामान्य है? क्या आपको पता है कि ऐसा कोई पैटर्न है?

में C#एक विस्तार विधि के लिए उपयोगी होगा

public static T AddTo(this T item, IList<T> list)
{
    list.Add(item);
    return item;
}

अन्य भाषाओं के बारे में कैसे? मुझे लगता है कि उनमें से अधिकांश में Itemकक्षा को एक ICollectionItemइंटरफ़ेस देना था ।


अद्यतन-1

मैं इसके बारे में थोड़ा और सोच रहा हूं और यह पैटर्न उदाहरण के लिए वास्तव में उपयोगी होगा यदि आप एक आइटम को कई संग्रह में नहीं जोड़ना चाहते हैं।

परीक्षण ICollectableइंटरफ़ेस:

interface ICollectable<T>
{
    // Gets a value indicating whether the item can be in multiple collections.
    bool CanBeInMultipleCollections { get; }

    // Gets a list of item's owners.
    List<ICollection<T>> Owners { get; }

    // Adds the item to a collection.
    ICollectable<T> AddTo(ICollection<T> collection);

    // Removes the item from a collection.
    ICollectable<T> RemoveFrom(ICollection<T> collection);

    // Checks if the item is in a collection.
    bool IsIn(ICollection<T> collection);
}

और एक नमूना कार्यान्वयन:

class NodeList : List<NodeList>, ICollectable<NodeList>
{
    #region ICollectable implementation.

    List<ICollection<NodeList>> owners = new List<ICollection<NodeList>>();

    public bool CanBeInMultipleCollections
    {
        get { return false; }
    }

    public ICollectable<NodeList> AddTo(ICollection<NodeList> collection)
    {
        if (IsIn(collection))
        {
            throw new InvalidOperationException("Item already added.");
        }

        if (!CanBeInMultipleCollections)
        {
            bool isInAnotherCollection = owners.Count > 0;
            if (isInAnotherCollection)
            {
                throw new InvalidOperationException("Item is already in another collection.");
            }
        }
        collection.Add(this);
        owners.Add(collection);
        return this;
    }

    public ICollectable<NodeList> RemoveFrom(ICollection<NodeList> collection)
    {
        owners.Remove(collection);
        collection.Remove(this);
        return this;
    }

    public List<ICollection<NodeList>> Owners
    {
        get { return owners; }
    }

    public bool IsIn(ICollection<NodeList> collection)
    {
        return collection.Contains(this);
    }

    #endregion
}

उपयोग:

var rootNodeList1 = new NodeList();
var rootNodeList2 = new NodeList();

var subNodeList4 = new NodeList().AddTo(rootNodeList1);

// Let's move it to the other root node:
subNodeList4.RemoveFrom(rootNodeList1).AddTo(rootNodeList2);

// Let's try to add it to the first root node again... 
// and it will throw an exception because it can be in only one collection at the same time.
subNodeList4.AddTo(rootNodeList1);

13
item.AddTo(items)मान लें कि आपके पास एक्सटेंशन विधियों के बिना एक भाषा है: प्राकृतिक या नहीं, AddTo का समर्थन करने के लिए प्रत्येक प्रकार को इस पद्धति की आवश्यकता होगी और इसे हर प्रकार के संग्रह के लिए प्रदान करना होगा जो कि सहायक हो। यह सब कुछ मैंने कभी सुना है के बीच निर्भरता शुरू करने का सबसे अच्छा उदाहरण की तरह है: पी - मुझे लगता है कि यहाँ झूठे आधार कुछ प्रोग्रामिंग अमूर्त को 'वास्तविक' जीवन में मॉडल करने की कोशिश कर रहे हैं। जो अक्सर गलत हो जाता है।
टिजिन

1
@ t3chb0t हेहे, अच्छी बात है। मैं सोच रहा था कि क्या आपकी पहली बोली जाने वाली भाषा प्रभावित करती है कि क्या निर्माण अधिक स्वाभाविक लगता है। मेरे लिए, केवल वही जो स्वाभाविक लगता है add(item, collection), लेकिन यह अच्छी ओओ शैली नहीं है।
किलन फ़ॉथ

3
@ t3chb0t बोली जाने वाली भाषा में, आप सामान्‍यत: या सजगता से पढ़ सकते हैं। "जॉन, कृपया इस सेब को जोड़ें जो आप ले जा रहे हैं।" बनाम "सेब को जोड़ा जाना चाहिए जो आप ले जा रहे हैं, जॉन।" OOP की दुनिया में, रिफ्लेक्सिव का ज्यादा मतलब नहीं है। आप आमतौर पर बोलने वाले किसी अन्य वस्तु से प्रभावित होने के लिए नहीं कहते हैं। OOP में यह सबसे नज़दीकी विज़िटर पैटर्न है । वहाँ एक कारण है कि हालांकि यह आदर्श नहीं है।
नील

3
यह एक बुरा विचार के आसपास एक अच्छा धनुष डाल रहा है
तेलस्टीन

3
@ t3chb0t आपको नॉन के राज्य को एक दिलचस्प पढ़ने के लिए मिल सकता है।
पौल

जवाबों:


51

नहीं, item.AddTo(items)यह अधिक प्राकृतिक नहीं है। मुझे लगता है कि आप इसे निम्नलिखित के साथ मिलाते हैं:

t3chb0t.Add(item).To(items)

आप सही हैं कि items.Add(item)प्राकृतिक अंग्रेजी भाषा के बहुत निकट नहीं है। लेकिन आप भी item.AddTo(items)प्राकृतिक अंग्रेजी भाषा में नहीं सुनते , क्या आप? आम तौर पर कोई है जो आइटम को सूची में जोड़ना चाहता है। सुपरमार्केट में काम करते समय या खाना बनाते और सामग्री डालते समय इसे करें।

प्रोग्रामिंग भाषाओं के मामले में, हमने इसे ऐसा बनाया है कि एक सूची दोनों करती है: इसकी वस्तुओं को संग्रहीत करना और उन्हें खुद को जोड़ने के लिए जिम्मेदार होना।

आपके दृष्टिकोण के साथ समस्या यह है कि एक आइटम के बारे में पता होना चाहिए कि एक सूची मौजूद है। लेकिन एक आइटम भी मौजूद हो सकता है अगर वहाँ कोई सूची नहीं थी, है ना? इससे पता चलता है कि इसे सूचियों की जानकारी नहीं होनी चाहिए। सूची किसी भी तरह से इसके कोड में नहीं होनी चाहिए।

हालाँकि, आइटम के बिना सूची मौजूद नहीं है (कम से कम वे बेकार होंगे)। इसलिए यह ठीक है अगर वे अपनी वस्तुओं के बारे में जानते हैं - कम से कम एक सामान्य रूप में।


4

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

ने कहा कि...

1. जावा नहीं

यहाँ जावा आपकी कोई मदद नहीं करता है, लेकिन कुछ भाषाओं में अधिक लचीली, एक्स्टेंसिबल सिंटैक्स है।

Scala में, items.add (आइटम) इस तरह दिखता है:

  item :: items

जहाँ :: एक ऑपरेटर है जो आइटम को सूचियों में जोड़ता है। जो आप चाहते हैं वह बहुत ज्यादा लगता है। यह वास्तव में के लिए कृत्रिम चीनी है

  items.::(item)

जहाँ :: एक स्काला सूची विधि है जो जावा की सूची.एड के समान प्रभावी है । इसलिए जब यह पहले संस्करण में लगता है जैसे आइटम करने के लिए खुद को जोड़ रहा है आइटम , सच में आइटम कर रही है जोड़ने। दोनों संस्करण मान्य स्काला हैं

यह चाल दो चरणों में की जाती है:

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

यदि आप बहुत सारे ऑपरेटरों के साथ सहज नहीं हैं और अपना AddTo चाहते हैं , तो Scala एक और विकल्प प्रदान करता है: निहित रूपांतरण। इसके लिए दो चरणों की आवश्यकता होती है

  1. एक रैपर क्लास बनाएं, जिसे कहते हैं, ListItem , जो अपने कंस्ट्रक्टर में एक आइटम लेता है और इसमें एक AddTo तरीका होता है, जो उस आइटम को किसी दी गई सूची में जोड़ सकता है।
  2. एक फ़ंक्शन बनाएं जो किसी आइटम को पैरामीटर के रूप में लेता है और उस आइटम वाले ListItem को वापस करता है । इसे निहित के रूप में चिह्नित करें ।

यदि निहित रूपांतरण सक्षम हैं और स्काला देखता है

  item addTo items

या

  item.addTo(items)

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

  ListItem.(item).addTo(items)

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

औपनिवेशिक-समाप्त ऑपरेटर बदसूरत हैं, लेकिन खतरा पैदा नहीं करते हैं।

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

2. जावा

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

3. टीएल; डॉ

कुछ अन्य भाषाओं की तरह, स्काला आपको अधिक प्राकृतिक वाक्य रचना में मदद कर सकता है। जावा केवल आपको बदसूरत, बारोक पैटर्न प्रदान कर सकता है।


2

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

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


यदि किसी फ्रेमवर्क को विभिन्न प्रकार के ऑब्जेक्ट संदर्भों को पहचानना होता है (उदाहरण के लिए उन लोगों के बीच अंतर करना जो स्वामित्व को अतिक्रमण करते हैं और जो नहीं करते हैं), तो इसका मतलब यह हो सकता है कि एक ऐसा साधन जिसके द्वारा स्वामित्व को एन्कैप्सुलेट किया जा सकता है, जो एक संग्रह के स्वामित्व को त्याग सकता है। इसे प्राप्त करने में सक्षम। यदि प्रत्येक वस्तु एक मालिक होने, thing.giveTo(collection)[के माध्यम से स्वामित्व को स्थानांतरित करने और collection"स्वीकार करने के लिए" इंटरफ़ेस "को लागू करने की आवश्यकता के लिए सीमित है] तो collectionस्वामित्व को जब्त करने की एक विधि को शामिल करने की तुलना में अधिक समझ होगी । बेशक ...
सुपरकैट

... जावा की अधिकांश चीजों में स्वामित्व की अवधारणा नहीं होती है, और एक वस्तु संदर्भ को संग्रह में संग्रहित किया जा सकता है, जिसमें वस्तु की पहचान नहीं की जाती है।
सुपरकैट

1

मुझे लगता है कि आप "ऐड" शब्द के साथ जुनूनी हैं। इसके बजाय एक वैकल्पिक शब्द की तलाश करें, जैसे कि "कलेक्ट", जो आपको पैटर्न में कोई बदलाव नहीं करने के साथ एक अधिक अंग्रेजी-अनुकूल वाक्यविन्यास देगा:

items.collect(item);

उपरोक्त विधि बिल्कुल वैसी ही है items.add(item);, जैसे एकमात्र अंतर अलग शब्द पसंद है, और अंग्रेजी में बहुत अच्छी तरह से और "स्वाभाविक रूप से" बहता है।

कभी-कभी, केवल नामकरण चर, विधियाँ, वर्ग, आदि पैटर्न के कर-निर्धारण को रोकेंगे।


collectकभी-कभी उन तरीकों के नाम के रूप में उपयोग किया जाता है जो किसी प्रकार के एक विलक्षण परिणाम में वस्तुओं के संग्रह को कम करते हैं (जो कि एक संग्रह भी हो सकता है)। यह सम्मलेन जावा स्टीम एपीआई द्वारा अपनाया गया था , जिसने इस संदर्भ में नाम का उपयोग बेहद लोकप्रिय बना दिया था। आपके संदर्भ में आपके द्वारा उल्लेखित संदर्भ में प्रयुक्त शब्द मैंने कभी नहीं देखा है। मैं नहीं बल्कि के साथ रहना होगा addयाput
१०

@toniedzwiedz, तो विचार करें pushया enqueue। यह बिंदु विशिष्ट उदाहरण का नाम नहीं है, लेकिन यह तथ्य कि एक अलग नाम अंग्रेजी-एस्क व्याकरण के लिए ओपी की इच्छा के करीब हो सकता है।
ब्रायन एस

1

हालांकि सामान्य मामले के लिए ऐसा कोई पैटर्न नहीं है (जैसा कि अन्य लोगों द्वारा समझाया गया है), जिस संदर्भ में एक समान पैटर्न की अपनी खूबियां हैं, वह ओआरएम में एक द्विदिश एक से कई एसोसिएशन है।

इस संदर्भ में आपके पास दो संस्थाएँ होंगी, आइए हम बताते हैं Parentऔर Child। एक माता-पिता के कई बच्चे हो सकते हैं, लेकिन प्रत्येक बच्चा एक माता-पिता का है। यदि आवेदन में एसोसिएशन को दोनों सिरों (द्विदिश) से नेविगेट करने की आवश्यकता होती है, तो आपके पास List<Child> childrenमाता-पिता वर्ग में और Parent parentबच्चे वर्ग में होंगे।

एसोसिएशन को हमेशा पाठ्यक्रम का पारस्परिक होना चाहिए। ORM समाधान आम तौर पर उन संस्थाओं पर लागू होते हैं जिन्हें वे लोड करते हैं। लेकिन जब आवेदन एक इकाई (या तो या नया) में हेरफेर कर रहा है, तो उसे उसी नियमों को लागू करना होगा। मेरे अनुभव में, आपको अक्सर एक ऐसी Parent.addChild(child)विधि मिल जाएगी जो चालान करती है Child.setParent(parent), जो सार्वजनिक उपयोग के लिए नहीं है। उत्तरार्द्ध में आपको आमतौर पर वही चेक मिलेंगे जो आपने अपने उदाहरण में लागू किए हैं। अन्य मार्ग को भी लागू किया जा सकता है: Child.addTo(parent)जो कॉल करता है Parent.addChild(child)। कौन सा मार्ग स्थिति से स्थिति में सबसे अच्छा है।


1

जावा में, एक विशिष्ट संग्रह चीजों को नहीं रखता है - यह चीजों के संदर्भ रखता है , या चीजों के संदर्भ की अधिक सटीक प्रतियां है । इसके विपरीत, डॉट-सदस्य सिंटैक्स का उपयोग आमतौर पर संदर्भ द्वारा पहचाने जाने वाली चीज़ पर किया जाता है, न कि केवल संदर्भ पर।

एक कटोरे में सेब रखने के दौरान सेब के कुछ पहलुओं को बदल दिया जाएगा (जैसे कि उसका स्थान), एक कागज़ में "ऑब्जेक्ट # 29521" कहे जाने वाली कागज़ की एक स्लिप रखकर सेब को किसी भी तरह से नहीं बदलेगा भले ही वह ऐसा हो ऑब्जेक्ट # 29521। इसके अलावा, क्योंकि संग्रह संदर्भों की प्रतियां रखते हैं, इसलिए कटोरे में "ऑब्जेक्ट # 29521" कहते हुए कागज की एक पर्ची रखने के बराबर कोई जावा नहीं है। इसके बजाय, कोई कागज की एक नई पर्ची पर संख्या # 29521 को कॉपी करता है, और मूल कटोरे को छोड़कर, जो कटोरे में जाएगा, उसे दिखाएगा।

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


इस पोस्ट को पढ़ना मुश्किल है (पाठ की दीवार)। क्या आप बेहतर आकार में आईएनजी को संपादित करेंगे ?
गनत

@gnat: क्या यह बेहतर है?
सुपरकैट

1
@gnat: क्षमा करें - एक नेटवर्क हिचकी ने संपादन को विफल करने के लिए पोस्ट करने का मेरा प्रयास किया। क्या आपको यह अब पसंद है?
सुपरकैट

-2

item.AddTo(items)इसका उपयोग नहीं किया जाता है क्योंकि यह निष्क्रिय है। सीएफ "आइटम को सूची में जोड़ा जाता है" और "कमरे को डेकोरेटर द्वारा चित्रित किया गया है"।

निष्क्रिय निर्माण ठीक हैं, लेकिन, कम से कम अंग्रेजी में, हम सक्रिय निर्माण को प्राथमिकता देते हैं।

OO प्रोग्रामिंग में, कर्ता अभिनेताओं को प्रमुखता देता है, न कि उन पर अभिनय किया जाता है, इसलिए हमारे पास है items.Add(item)। सूची कुछ करने की चीज है। यह अभिनेता है, इसलिए यह अधिक प्राकृतिक तरीका है।


यह इस बात पर निर्भर करता है कि आप कहां खड़े हैं ;-) - सापेक्षता का सिद्धांत - आप कह सकते हैं कि list.Add(item) किसी आइटम के बारे में सूची में जोड़ा जा रहा है या सूची में कोई आइटम जोड़ा जाता है या आइटम के बारे item.AddTo(list) में सूची में खुद को जोड़ता है या मैं आइटम जोड़ता हूं सूची या जैसे आपने कहा है कि आइटम को सूची में जोड़ा गया है - वे सभी सही हैं। तो सवाल यह है कि अभिनेता कौन है और क्यों? एक आइटम भी एक अभिनेता है और यह एक समूह (सूची) में शामिल होना चाहता है न कि समूह इस आइटम को चाहता है;; आइटम सक्रिय रूप से एक समूह में होने के लिए कार्य करता है।
t3chb0t

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

... हालांकि यह अक्सर पसंद करता है जब उसके पास Parentसंपत्ति होती है। बेशक अंग्रेजी नहीं देशी मई भाषा है, लेकिन जहाँ तक मैं पता चाहने निष्क्रिय नहीं है, जब तक कि मैं चाहता था कर रहा हूँ या वह मुझे कुछ करने के लिए चाहता है ] -;
t3chb0t

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

लेकिन List<T>(कम से कम पाया गया System.Collections.Generic) किसी भी Parentसंपत्ति का अद्यतन नहीं करता है । यदि यह सामान्य माना जाता है तो यह कैसे हो सकता है? इसकी सामग्री को जोड़ने के लिए आमतौर पर कंटेनर की जिम्मेदारी होती है।
आर्टुरो टॉरेस सैंचेज़
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.