সংগ্রহে আইটেম যুক্ত করার আরও "প্রাকৃতিক" উপায়ের জন্য কি কোনও প্যাটার্ন রয়েছে? [বন্ধ]


13

আমি মনে করি সংগ্রহে কিছু যুক্ত করার সর্বাধিক সাধারণ উপায় হ'ল কোনও ধরণের Addপদ্ধতি ব্যবহার করা যা কোনও সংগ্রহ সরবরাহ করে:

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

এবং এটি সম্পর্কে অস্বাভাবিক কিছুই নেই।

আমি ভাবছি তবে আমরা কেন এইভাবে করি না:

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

এটি প্রথম পদ্ধতিটি একরকম আরও প্রাকৃতিক বলে মনে হচ্ছে । এর সাথে অ্যান্ডওয়ান্টেজ থাকবে যখন 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)ধরুন আপনার কাছে এক্সটেনশন পদ্ধতি ছাড়াই একটি ভাষা রয়েছে: প্রাকৃতিক বা না, অ্যাডটোর সমর্থন করার জন্য প্রতিটি ধরণের এই পদ্ধতির প্রয়োজন হবে এবং এডেন্ডিং সমর্থনকারী প্রতিটি ধরণের সংগ্রহের জন্য এটি সরবরাহ করবে। এটি আমি শুনেছি এমন কিছুর মধ্যে নির্ভরতা প্রবর্তনের সর্বোত্তম উদাহরণের মতো : পি - আমি মনে করি যে এখানে মিথ্যা ভিত্তি 'বাস্তব' জীবনের কিছু প্রোগ্রামিং বিমূর্ততা মডেল করার চেষ্টা করছে। এটি প্রায়শই ভুল হয়ে যায়।
stijn

1
@ t3chb0t হেই, ভাল কথা। আমি ভাবছিলাম যে আপনার প্রথম কথ্য ভাষাটি নির্মাণকে আরও প্রাকৃতিক বলে মনে করে কিনা তা প্রভাবিত করে। আমার কাছে কেবল একমাত্র যা প্রাকৃতিক মনে হয় add(item, collection)তবে তা ওও স্টাইল ভাল নয় style
কিলিয়ান ফট

3
@ t3chb0t কথ্য ভাষায়, আপনি জিনিসগুলি স্বাভাবিকভাবে বা প্রতিবিম্বিতভাবে পড়তে পারেন। "জন, দয়া করে আপনি যা বহন করছেন তাতে এই আপেলটি যুক্ত করুন" " বনাম "আপনি যা বহন করছেন তাতে আপেল যুক্ত করা উচিত John" ওওপি-র বিশ্বে রিফ্লেক্সিভ বেশি বোঝায় না। আপনি অন্য কোনও বিষয় সাধারণত বলার দ্বারা প্রভাবিত হতে বলেন না। ওওপি-র মধ্যে এটির নিকটতম স্থানটি হল ভিজিটর ধরণ । একটি কারণ আছে যে এটি যদিও আদর্শ নয়।
নিল

3
এটি একটি খারাপ ধারণাটির চারপাশে একটি দুর্দান্ত ধনুক রাখছে
তেলস্তিন

3
@ t3chb0t আপনি খুঁজে পেতে পারেন কিং অফ কিং অব আকর্ষণীয় পঠন।
পল

উত্তর:


51

না, item.AddTo(items)এটি বেশি প্রাকৃতিক নয়। আমি মনে করি আপনি এটি নীচের সাথে মিশ্রিত করুন:

t3chb0t.Add(item).To(items)

আপনি ঠিক যে items.Add(item)প্রাকৃতিক ইংরেজি ভাষার খুব কাছাকাছি না। তবে আপনিও item.AddTo(items)প্রাকৃতিক ইংরেজি ভাষায় শুনতে পান না , তাই না? সাধারণত এমন কেউ আছেন যাকে তালিকায় আইটেম যুক্ত করার কথা রয়েছে। সুপারমার্কেটে কাজ করার সময় বা রান্না করার সময় এবং উপাদানগুলি যুক্ত করার সময় তা হয়ে উঠুন।

প্রোগ্রামিং ভাষার ক্ষেত্রে, আমরা এটি তৈরি করেছি যাতে একটি তালিকা উভয়ই করে: এটির আইটেমগুলি সংরক্ষণ করে এবং সেগুলিকে নিজের মধ্যে যুক্ত করার জন্য দায়বদ্ধ।

আপনার পদ্ধতির সাথে সমস্যাটি হ'ল কোনও আইটেমটি সচেতন হতে হবে যে তালিকা উপস্থিত রয়েছে। তবে কোনও আইটেম উপস্থিত থাকতে পারে এমনকি যদি কোনও তালিকা নাও থাকে, তাই না? এটি দেখায় যে এটি তালিকা সম্পর্কে সচেতন হওয়া উচিত নয়। তালিকা কোনওভাবেই এর কোডে দেখা উচিত নয়।

তালিকাগুলি আইটেম ছাড়া অস্তিত্ব নেই (কমপক্ষে তারা বেহুদা হবে)। সুতরাং তাদের আইটেমগুলি সম্পর্কে কমপক্ষে জেনেরিক আকারে জেনে থাকলে এটি জরিমানা form


4

উদ্বেগ বিচ্ছিন্ন হওয়ার সমস্যা সম্পর্কে @ ভ্যালেনটারি ঠিকই সঠিক। শ্রেণিগুলির বিভিন্ন সংগ্রহের মধ্যে সেগুলি থাকতে পারে সে সম্পর্কে কিছুই জানতে হবে না। প্রতিবার নতুন ধরণের সংগ্রহ তৈরি করার সময় আপনি আইটেম শ্রেণি পরিবর্তন করতে চাইবেন না ।

বলেছিল ...

1. জাভা নয়

জাভা এখানে আপনার জন্য কোনও সহায়তা নয় তবে কিছু ভাষায় আরও নমনীয়, এক্সটেনসিবল সিনট্যাক্স রয়েছে।

স্কেলে আইটেম.এডড (আইটেম) এর মতো দেখতে:

  item :: items

যেখানে :: অপারেটর যা তালিকায় আইটেম যুক্ত করে। আপনি যা চান তা খুব মনে হয়। এটি আসলে সিনট্যাকটিক চিনির জন্য

  items.::(item)

যেখানে :: একটি স্কালার তালিকা পদ্ধতি যা কার্যকরভাবে জাভা এর list.add এর সমতুল্য । এটি প্রথম সংস্করণে দেখে মনে হচ্ছে যেন আইটেম নিজেকে আইটেমগুলিতে যুক্ত করছে , সত্য আইটেমগুলিতে অ্যাড করছে। উভয় সংস্করণ বৈধ স্কেলা হয়

এই কৌশল দুটি ধাপে সম্পন্ন করা হয়:

  1. স্কালায় অপারেটররা আসলেই কেবল পদ্ধতি methods আপনি যদি স্ক্যালায় জাভা তালিকাগুলি আমদানি করেন, তবে আইটেমস.এডড (আইটেম) এ আইটেম যুক্ত করে আইটেমও লেখা যেতে পারে । স্কেলে, 1 + 2 আসলে 1 + + (2) । বিন্দু এবং বন্ধনীগুলির চেয়ে স্পেস সহ সংস্করণে স্কালা প্রথম বস্তুটি দেখে, পরবর্তী শব্দের সাথে মেলে এমন একটি পদ্ধতির সন্ধান করে এবং (যদি পদ্ধতিটি পরামিতি নেয়) পরবর্তী পদ্ধতিটি (বা জিনিসগুলি) সেই পদ্ধতিতে পাস করে।
  2. স্কালায়, অপারেটরগুলি যেগুলি কোলনে শেষ হয় তারা বামের চেয়ে ডান-অ্যাসোসিয়েটিভ হয়। সুতরাং যখন স্কালা পদ্ধতিটি দেখে, তখন এটি ডানদিকে পদ্ধতির মালিককে সন্ধান করে এবং বামে থাকা মানটি ফিড করে।

আপনি যদি প্রচুর অপারেটর নিয়ে স্বাচ্ছন্দ্য বোধ করেন না এবং আপনার অ্যাডটো চান , স্কালা আরও একটি বিকল্প প্রস্তাব করে: অন্তর্নিহিত রূপান্তর। এর জন্য দুটি পদক্ষেপ প্রয়োজন

  1. একটি রাপার ক্লাস নামক বলুন, তৈরি করুন ListItem যা লাগে আইটেমটি তার কন্সট্রাকটর এবং একটি হয়েছে addTo পদ্ধতি যা একটি প্রদত্ত লিস্টে ঐ আইটেমটির যোগ করতে পারেন।
  2. একটি ফাংশন তৈরি করুন যা কোনও আইটেমকে প্যারামিটার হিসাবে গ্রহণ করে এবং সেই আইটেমযুক্ত একটি তালিকা আইটেম দেয়অন্তর্নিহিত হিসাবে চিহ্নিত করুন ।

যদি অন্তর্নিহিত রূপান্তরগুলি সক্ষম হয় এবং স্কেলা দেখে

  item addTo items

অথবা

  item.addTo(items)

এবং আইটেমের addTo নেই , এটি কোনও অন্তর্নিহিত রূপান্তর কার্যের জন্য বর্তমান সুযোগটি অনুসন্ধান করবে। রূপান্তর ফাংশন কোন একটি টাইপ যা ফেরৎ যদি না একটি আছে addTo পদ্ধতি, এই ঘটনার:

  ListItem.(item).addTo(items)

এখন, আপনি আপনার স্বাদে আরও অন্তর্নিহিত রূপান্তরগুলির রুটটি খুঁজে পেতে পারেন তবে এটি বিপদ যুক্ত করে, কারণ যদি আপনি প্রদত্ত প্রসঙ্গে সমস্ত প্রচ্ছন্ন রূপান্তর সম্পর্কে স্পষ্টভাবে অবগত না হন তবে কোড অপ্রত্যাশিত জিনিসগুলি করতে পারে। এই কারণেই এই বৈশিষ্ট্যটি আর স্ক্যালায় ডিফল্টরূপে সক্ষম হয় না। (তবে, আপনি নিজের কোডটিতে এটি সক্ষম করবেন কিনা তা আপনি বেছে নিতে পারেন, তবে অন্যান্য ব্যক্তির লাইব্রেরিতে আপনি এর অবস্থান সম্পর্কে কিছুই করতে পারবেন না Here এখানে ড্রাগন থাকুন)।

কোলন-টার্মিনেটেড অপারেটররা কুরুচিপূর্ণ তবে হুমকি দেয় না।

উভয় পদ্ধতির উদ্বেগ পৃথকীকরণের নীতি সংরক্ষণ করে। আপনি এটি দেখতে এমনভাবে তৈরি করতে পারেন যেন কোনও আইটেম সংগ্রহের বিষয়ে জানে তবে কাজটি অন্য কোথাও করা হয়েছে। অন্য কোনও ভাষা যা আপনাকে এই বৈশিষ্ট্যটি দিতে চায় তা কমপক্ষে সতর্ক হওয়া উচিত।

2. জাভা

জাভাতে, যেখানে সিনট্যাক্সটি আপনার দ্বারা এক্সটেনসিবল হয় না, আপনি সবচেয়ে ভাল যা করতে পারেন তা হ'ল এক ধরণের মোড়ক / সাজসজ্জার শ্রেণি তৈরি করা যা তালিকাগুলি সম্পর্কে জানে। আপনার আইটেমগুলিকে তালিকায় রাখা হয়েছে এমন ডোমেনে, আপনি সেগুলিতে এটি মোড়ানো করতে পারেন। যখন তারা সেই ডোমেনটি ছেড়ে যায়, তাদের বাইরে নিয়ে যান। সম্ভবত দর্শনার্থীর প্যাটার্নটি সবচেয়ে কাছের।

3. টিএল; ডা

অন্যান্য কয়েকটি ভাষার মতো স্কালাও আপনাকে আরও প্রাকৃতিক বাক্য গঠনতে সহায়তা করতে পারে। জাভা কেবল আপনাকে কুৎসিত, বারোক নকশার প্রস্তাব দিতে পারে।


2

আপনার এক্সটেনশন পদ্ধতির সাহায্যে আপনাকে এখনও অ্যাড () এ কল করতে হবে যাতে এটি আপনার কোডে কার্যকর কিছু যোগ না করে। আপনার অ্যাড্টো পদ্ধতিটি অন্য কোনও প্রক্রিয়াজাতকরণ না করে এটির অস্তিত্বের কোনও কারণ নেই। এবং কোডিং কোডের কোনও কার্যকরী উদ্দেশ্য নেই যা পাঠযোগ্যতা এবং রক্ষণাবেক্ষণের পক্ষে খারাপ।

আপনি যদি জেনারিক না রেখে সমস্যাগুলি আরও প্রকট হয়ে ওঠেন। আপনার কাছে এখন একটি আইটেম রয়েছে যা এটি হতে পারে বিভিন্ন ধরণের সংগ্রহ সম্পর্কে জানতে হবে That এটি একক দায়িত্বের নীতি লঙ্ঘন করে। কেবল কোনও আইটেমই এর ডেটা ধারক নয়, এটি সংগ্রহগুলিও পরিচালনা করে। এই কারণেই আমরা কোডের টুকরা পর্যন্ত সংগ্রহগুলিতে আইটেম যুক্ত করার দায় ছেড়ে দিচ্ছি যা সেগুলি উভয়ই গ্রাস করে।


যদি কোনও কাঠামো বিভিন্ন ধরণের অবজেক্টের রেফারেন্সগুলি স্বীকৃতি দেয় (উদাহরণস্বরূপ যেগুলি মালিকানকে encapsulate করে এবং যা না তাদের মধ্যে পার্থক্য করা), এটির এমন কোনও উপায় রয়েছে যার দ্বারা মালিকানা encapsulates এমন একটি রেফারেন্স একটি সংগ্রহের সাথে মালিকানা ছেড়ে দিতে পারে যার অর্থ ছিল এটি গ্রহণ করতে সক্ষম যদি প্রতিটি জিনিস একজনের মালিকের মধ্যে সীমাবদ্ধ থাকে তবে মালিকানা হস্তান্তর thing.giveTo(collection)[এবং collection"গ্রহণযোগ্যতা" ইন্টারফেস বাস্তবায়নের প্রয়োজন ] collectionমালিকানা দখল করে এমন একটি পদ্ধতি অন্তর্ভুক্ত করার চেয়ে আরও বেশি অর্থবোধ করতে পারে। অবশ্যই ...
সুপারক্যাট

... জাভাতে বেশিরভাগ জিনিসের মালিকানার ধারণা নেই এবং এর সাথে চিহ্নিত বস্তুটি জড়িত না করে কোনও অবজেক্ট রেফারেন্স কোনও সংগ্রহে সংরক্ষণ করা যেতে পারে।
সুপারক্যাট

1

আমি মনে করি আপনি "অ্যাড" শব্দটি অবলম্বন করছেন। পরিবর্তে বিকল্প সংগ্রহ করার চেষ্টা করুন, যেমন "সংগ্রহ", যা আপনাকে বিন্যাসে কোনও পরিবর্তন ছাড়াই আরও একটি ইংরেজী-বান্ধব বাক্য গঠন দেবে:

items.collect(item);

উপরের পদ্ধতিটি হুবহু একই রকম items.add(item);, কেবলমাত্র পার্থক্যটি পৃথক পৃথক শব্দের পছন্দ এবং ইংরেজিতে খুব সুন্দর এবং "প্রাকৃতিকভাবে" প্রবাহিত।

কখনও কখনও কেবলমাত্র নামকরণের ভেরিয়েবল, পদ্ধতি, ক্লাস ইত্যাদি প্যাটার্নটির ট্যাক্স পুনঃনির্ধারণকে আটকাতে পারে prevent


collectকখনও কখনও এমন পদ্ধতিগুলির নাম হিসাবে ব্যবহৃত হয় যা আইটেমের সংগ্রহকে একরকম একক ফলাফলের মধ্যে হ্রাস করে (এটি একটি সংগ্রহও হতে পারে)। এই কনভেনশনটি জাভা স্টিম এপিআই গ্রহণ করেছিল , যা এই প্রসঙ্গে নামের ব্যবহারকে অত্যন্ত জনপ্রিয় করে তুলেছিল। আপনি আপনার উত্তরে উল্লেখ করেছেন এমন প্রসঙ্গে ব্যবহৃত শব্দটি আমি কখনও দেখিনি। আমি বরং দিয়ে বিদ্ধ চাই addবাput
toniedzwiedz

@ টোনজিডভিয়েজ, সুতরাং বিবেচনা করুন pushবা enqueue। বিষয়টি নির্দিষ্ট উদাহরণের নাম নয়, তবে ভিন্ন একটি নামটি ইংরেজি-এস্কো ব্যাকরণের জন্য ওপি-র ইচ্ছাটির আরও কাছাকাছি থাকতে পারে।
ব্রায়ান এস

1

যদিও সাধারণ ক্ষেত্রে (যেমন অন্যদের দ্বারা ব্যাখ্যা করা হয়েছে) এর জন্য এমন কোনও নিদর্শন নেই, তবে একই প্রসঙ্গে যে অনুরূপ প্যাটার্নটির গুণাগুণ রয়েছে তা হল ওআরএমের দ্বি-দিকনির্দেশক এক থেকে বহু সংযোগ association

এ প্রসঙ্গে দুই সত্ত্বা আছে চাই, এর কথা বলা যাক Parentএবং Child। একটি পিতামাতার অনেক সন্তান থাকতে পারে তবে প্রতিটি শিশু এক পিতামাতার অন্তর্ভুক্ত। যদি অ্যাপ্লিকেশনটির উভয় প্রান্তের (দ্বি নির্দেশমূলক) অ্যাসোসিয়েশনটি প্রয়োজন হয় তবে List<Child> childrenআপনার প্যারেন্ট ক্লাসে এবং Parent parentশিশু শ্রেণিতে একটি থাকবে।

সমিতি অবশ্যই সর্বদা পারস্পরিক হতে হবে। ORM সমাধানগুলি সাধারণত লোড হওয়া সত্তাগুলিতে এটি প্রয়োগ করে। কিন্তু যখন অ্যাপ্লিকেশনটি কোনও সত্তাকে হস্তান্তর করছে (হয় তা বহাল থাকে বা নতুন), এটি একই নিয়মগুলি প্রয়োগ করতে হবে। আমার অভিজ্ঞতায় আপনি বেশিরভাগ ক্ষেত্রে এমন একটি Parent.addChild(child)পদ্ধতি খুঁজে পাবেন Child.setParent(parent)যা অনুরোধ করে যা জনসাধারণের ব্যবহারের জন্য নয়। পরবর্তীকালে আপনি সাধারণত একই পরীক্ষা করে দেখতে পাবেন যা আপনি আপনার উদাহরণে প্রয়োগ করেছেন। অন্য রুটটি তবে প্রয়োগ করা যেতে পারে: Child.addTo(parent)যা কল করে Parent.addChild(child)। কোন রুটটি পরিস্থিতি থেকে পৃথক পৃথক।


1

জাভা, একটি টিপিক্যাল সংগ্রহে না রাখা জিনিষ --it ঝুলিতে রেফারেন্স জিনিষ, বা আরো সঠিকভাবে কপি এর রেফারেন্স জিনিষ। বিপরীতে, বিন্দু-সদস্য সিনট্যাক্সটি সাধারণত রেফারেন্সের পরিবর্তে একটি রেফারেন্স দ্বারা চিহ্নিত জিনিসটির উপরে কাজ করতে ব্যবহৃত হয়।

একটি পাত্রে একটি আপেল রাখার সময় আপেলের কিছু দিক (যেমন এর অবস্থান) বদলে যায়, কাগজের একটি স্লিপে "অবজেক্ট # 29521" বলে একটি পাত্রে রেখে আপেলটিকে কোনওভাবেই পরিবর্তন করা যায় না যদিও তা ঘটেছিল অবজেক্ট # 29521। আরও, সংগ্রহগুলি রেফারেন্সের অনুলিপি রাখার কারণে, "বাজেট # 29521" বলে একটি পাত্রে কাগজের স্লিপ রাখার সমতুল্য জাভা নেই। পরিবর্তে, একটি কাগজের নতুন স্লিপে # 29521 নম্বরটি অনুলিপি করে, এবং সেই বাটিটিকে (দেবে না) দেখান, যা তাদের নিজস্ব অনুলিপি তৈরি করবে, আসলটিকে অকারণে রেখে।

প্রকৃতপক্ষে, যেহেতু জাভাতে অবজেক্ট রেফারেন্স ("কাগজের স্লিপগুলি") নিষ্ক্রিয়ভাবে পর্যবেক্ষণ করা যায়, তাই রেফারেন্সগুলি বা এর দ্বারা চিহ্নিত বস্তুগুলির সাথে তাদের কী করা হচ্ছে তা জানার কোনও উপায় নেই। কিছু ধরণের সংগ্রহ রয়েছে যা কেবলমাত্র বস্তুর প্রতি একগুচ্ছ রেফারেন্স রাখার পরিবর্তে সংগ্রহের অস্তিত্ব সম্পর্কে কিছুই জানতে পারে না, পরিবর্তে এতে আবৃত বস্তুর সাথে দ্বি-দিকীয় সম্পর্ক স্থাপন করে। এই জাতীয় কিছু সংগ্রহের সাহায্যে কোনও সংগ্রহের সাথে নিজেকে যুক্ত করার জন্য কোনও পদ্ধতি জিজ্ঞাসা করা বুদ্ধিমান হতে পারে (বিশেষত যদি কোনও জিনিস কেবল একবারে এই জাতীয় সংগ্রহের জন্য সক্ষম হয়)। যদিও সাধারণভাবে, বেশিরভাগ সংগ্রহগুলি সেই প্যাটার্নের সাথে খাপ খায় না এবং those রেফারেন্সগুলি দ্বারা চিহ্নিত আইটেমগুলির অংশে কোনও রকম জড়িততা ছাড়াই অবজেক্টের রেফারেন্স গ্রহণ করতে পারে।


এই পোস্টটি পড়ার চেয়ে শক্ত (পাঠ্যের প্রাচীর)। তুমি কিছু মনে করবে সম্পাদন করা একটি ভাল আকৃতি সেটিকে ing?
gnat

@ গ্যানাট: এটা কি আরও ভাল?
সুপারক্যাট

1
@ গ্যানাট: দুঃখিত - একটি নেটওয়ার্ক হিচাপের কারণে সম্পাদনাটি পোস্ট করার চেষ্টা আমার ব্যর্থ হয়েছে to আপনি এখন এটি ভাল পছন্দ করেন?
সুপারক্যাট

-2

item.AddTo(items)এটি প্যাসিভ কারণ ব্যবহার করা হয় না। সিএফ "আইটেমটি তালিকায় যুক্ত করা হয়েছে" এবং "ঘরটি সাজসজ্জা দ্বারা আঁকা"।

প্যাসিভ নির্মাণগুলি ভাল, তবে কমপক্ষে ইংরেজী ভাষায়, আমরা সক্রিয় নির্মাণগুলিকে পছন্দ করি।

ওও প্রোগ্রামিংয়ে, ক্ষমাপ্রার্থী অভিনেতাদেরকে গুরুত্ব দেয়, তার উপর অভিনয় করা নয়, তাই আমাদের রয়েছে items.Add(item)। তালিকাটি কিছু করার জিনিস। এটি অভিনেতা, সুতরাং এটি আরও প্রাকৃতিক উপায়।


এটি যেখানে আপনি দাঁড়িয়ে আছেন তার উপর নির্ভর করে ;-) - আপেক্ষিকতা তত্ত্ব - আপনি list.Add(item) তালিকার সাথে কোনও আইটেম যুক্ত করা হচ্ছে বা তালিকা একটি আইটেম যুক্ত করে বা item.AddTo(list) আইটেমটি তালিকায় নিজেকে যুক্ত করে বা আমি আইটেমটি যুক্ত করি সে সম্পর্কে আপনি একই কথা বলতে পারেন তালিকায় বা মত আপনি বলেছেন আইটেমটি তালিকায় যুক্ত করা হয়েছে - এগুলি সবই সঠিক। তাহলে প্রশ্ন হল অভিনেতা কে এবং কেন? একটি আইটেমও একজন অভিনেতা এবং এটি একটি গ্রুপে যোগ দিতে চায় (তালিকাতে) গ্রুপটি এই আইটেমটি রাখতে চায় না ;-) আইটেমটি একটি গ্রুপে থাকতে সক্রিয়ভাবে কাজ করে।
t3chb0t

অভিনেতা হ'ল সক্রিয় জিনিস করা জিনিস। "চাই" একটি প্যাসিভ জিনিস। প্রোগ্রামিংয়ে, এটি সেই তালিকা যা পরিবর্তিত হয় যখন কোনও আইটেম যুক্ত করা হয় তখন আইটেমটি একেবারেই পরিবর্তন করা উচিত নয়।
ম্যাট এলেন

... যদিও এটি প্রায়ই Parentসম্পত্তি থাকে যখন পছন্দ করে । বোঝা যাচ্ছে যে নেতারা ইংরেজি না নেটিভ may ভাষা কিন্তু যতদূর আমি জানি অনুপস্থিত প্যাসিভ নয় যদি না আমি চেয়েছিলেন করছি বা তিনি আমাকে কিছু করতে চায় ] -;
t3chb0t

আপনি যখন কিছু চান তখন আপনি কোন পদক্ষেপটি করেন? এটাই আমার বক্তব্য। এটি অগত্যা ব্যাকরণগতভাবে প্যাসিভ নয় তবে শব্দার্থগতভাবে এটি। ডাব্লুআরটি পিতামাতার গুণাবলী, নিশ্চিত যে এটি একটি ব্যতিক্রম, তবে সমস্ত হিরিস্টিকস সেগুলি রয়েছে।
ম্যাট এলেন

তবে List<T>(অন্তত একটিতে পাওয়া যায় System.Collections.Generic) কোনও Parentসম্পত্তি আপডেট করে না । এটি জেনেরিক হওয়ার কথা যদি হয় তবে কীভাবে? বিষয়বস্তু যুক্ত করার জন্য সাধারণত ধারকটির দায়িত্ব।
আর্টুরো টরেস সানচেজ
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.