ভিন্নজাতীয় তালিকার জন্য একটি নির্দিষ্ট উদ্দেশ্য আছে?


13

সি # এবং জাভা ব্যাকগ্রাউন্ড থেকে আসার পরে, আমি আমার তালিকাগুলি একজাতীয় হওয়ার জন্য অভ্যস্ত এবং এটি আমার কাছে উপলব্ধি করে। আমি যখন লিস্পটিকে বাছাই শুরু করলাম তখন আমি লক্ষ্য করেছি যে তালিকাগুলি ভিন্ন ভিন্ন হতে পারে। আমি যখন dynamicসি # তে কীওয়ার্ডটি নিয়ে ঘুরতে শুরু করলাম তখন আমি লক্ষ্য করেছি যে, সি # ৪.০ হিসাবে, ভিন্নধর্মী তালিকাও থাকতে পারে:

List<dynamic> heterogeneousList

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


1
আপনি কি বোঝাতে চেয়েছিলেন ... আমি লক্ষ্য করেছি যে তালিকাগুলি ভিন্ন ভিন্ন হতে পারে ...?
বিশ্ব প্রকৌশলী

List<dynamic>সহজভাবে করা থেকে কীভাবে (আপনার প্রশ্নের জন্য) আলাদা List<object>?
পিটার কে।

@ ওয়ার্ল্ড ইঞ্জিনিয়ার হ্যাঁ, আমি করি। আমি আমার পোস্ট আপডেট করেছি। ধন্যবাদ!
জেটি

@PeterK। আমি প্রতিদিনের ব্যবহারের জন্য অনুমান করি, কোনও পার্থক্য নেই। তবে, সি # তে প্রতিটি ধরণের সিস্টেম থেকে আসে না bউবজেক্ট তাই পার্থক্য রয়েছে এমন প্রান্তের ক্ষেত্রেও ঘটতে পারে।
জেটি

উত্তর:


16

কাগজ দৃঢ়ভাবে অসমসত্ত্ব সংগ্রহগুলি টাইপ ওলেগ Kiselyov দ্বারা, রালফ Lämmel এবং Keean Schupke না শুধুমাত্র মধ্যে Haskell অসমসত্ত্ব তালিকার একটি বাস্তবায়ন, কিন্তু যখন, কেন এবং কিভাবে আপনি HLists ব্যবহার করেন একটি প্রেরণার উদাহরণ রয়েছে। বিশেষত, তারা এটি টাইপ-নিরাপদ সংকলন-সময় পরীক্ষা করা ডাটাবেস অ্যাক্সেসের জন্য ব্যবহার করছে। (লিনকিউ ভাবুন, বাস্তবে, তারা যে কাগজটি উল্লেখ করছেন তারা হ'ল হ্যাশেল পেপার যা এরিক মেইজার এট আল দ্বারা লিঙ্ককে নিয়ে গিয়েছিল))

এইচলিস্ট পেপারের সূচনা অনুচ্ছেদ থেকে উদ্ধৃতি:

বৈকল্পিক সংগ্রহের জন্য কল করে এমন সাধারণ উদাহরণগুলির একটি ওপেন-এন্ডের তালিকা রয়েছে:

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

নোট করুন যে আপনি আপনার প্রশ্নে যে উদাহরণ দিয়েছেন তা আসলে শব্দটি সাধারণত ব্যবহৃত হয় সেই অর্থে ভিন্ন ভিন্ন তালিকা নয়। এগুলি দুর্বলভাবে টাইপ করা বা টাইপযুক্ত তালিকাগুলি। বস্তুত, তারা আসলে সমজাতীয় তালিকা, যেহেতু সব উপাদান একই ধরণের আছেন: objectবা dynamic। এরপরে আপনাকে কাস্টমগুলি বা চেক না করা instanceofপরীক্ষা বা এমন কিছু করতে বাধ্য করা হয় , যাতে উপাদানগুলির সাথে অর্থপূর্ণভাবে কাজ করতে সক্ষম হয়, যা তাদের দুর্বলভাবে টাইপ করে।


লিঙ্কটি এবং আপনার প্রতিক্রিয়া জন্য ধন্যবাদ। আপনি একটি ভাল বক্তব্য রাখেন যে তালিকাগুলি সত্যই ভিন্ন ভিন্ন নয় বরং দুর্বলভাবে টাইপ করা আছে। আমি সেই কাগজটি পড়ার অপেক্ষায় রয়েছি (সম্ভবত আগামীকাল, আজ রাত্রে মাঝামাঝি সময় পেয়েছি :))
জেটি

5

দীর্ঘ গল্প সংক্ষিপ্ত, ভিন্ন ভিন্ন ধারক নমনীয়তার জন্য রানটাইম পারফরম্যান্স বাণিজ্য করে। আপনি যদি নির্দিষ্ট ধরণের জিনিসকে বিবেচনা না করে একটি "স্টাফের তালিকা" রাখতে চান তবে ভিন্ন ভিন্নতা যাবার উপায়। লিপসগুলি বৈশিষ্ট্যগতভাবে গতিশীলভাবে টাইপ করা হয় এবং বেশিরভাগ সবকিছুই যাইহোক যাইহোক বক্সযুক্ত মানগুলির একটি তালিকা-তালিকা, তাই ক্ষুদ্রতর পারফরম্যান্সের হিট আশা করা যায়। লিস্প বিশ্বে প্রোগ্রামারের উত্পাদনশীলতা রানটাইম পারফরম্যান্সের চেয়ে বেশি গুরুত্বপূর্ণ হিসাবে বিবেচিত হয়।

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

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


1
"তবে, কখনও কখনও আপনি একটি ভিন্ন ভিন্ন ধারক চান এবং আপনার প্রয়োজন হলে এটি রাখার অনুমতি দেওয়া উচিত।" - কেন যদিও? এটাই আমার প্রশ্ন। আপনার কেন কখনও এলোমেলো তালিকার মধ্যে একগুচ্ছ ডেটা হজপজ করতে হবে?
জেটি

@ জেটি: বলুন আপনার কাছে বিভিন্ন ধরণের ব্যবহারকারী-প্রবেশের সেটিংসের একটি তালিকা রয়েছে। আপনি একটি ইন্টারফেস তৈরি করতে পারেন IUserSettingএবং এটি বেশ কয়েকবার প্রয়োগ করতে পারেন , বা জেনেরিক তৈরি করতে পারেন UserSetting<T>তবে স্থির টাইপিংয়ের একটি সমস্যা হ'ল এটি কীভাবে ব্যবহৃত হবে তা সুনির্দিষ্টভাবে জানার আগে আপনি একটি ইন্টারফেসটি সংজ্ঞায়িত করছেন। আপনি পূর্ণসংখ্যার সেটিংস দিয়ে যে জিনিসগুলি করেন সেগুলি সম্ভবত স্ট্রিং সেটিংসের সাথে করা জিনিসগুলির থেকে খুব আলাদা, তাই কোন সাধারণ ইন্টারফেসে কোনও ক্রিয়াকলাপ বোধগম্য হয়? যতক্ষণ না আপনি নিশ্চিতভাবে অবগত হন, ততক্ষণে যুক্তিযুক্তভাবে গতিশীল টাইপিং ব্যবহার করা ভাল এবং পরে এটি কংক্রিট করা ভাল।
জন পুরী

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

@ জেটি: এটি মূলত একই সমস্যা, যদিও — সর্বজনীন বেস শ্রেণিটি প্রথম স্থানে থাকা উচিত নয় কারণ এটি যে কোনও ক্রিয়াকলাপ নির্ধারণ করে না কেন, এই ধরণের অপারেশনগুলি বোঝায় না এমন একটি প্রকার থাকবে। তবে যদি সি # এর objectপরিবর্তে একটি ব্যবহার করা সহজ করে তোলে dynamicতবে অবশ্যই, পূর্ববর্তীটি ব্যবহার করুন।
জন পুরী

1
@ জেটি: পলিমারফিজমটি এটিই। তালিকায় বেশ কয়েকটি "ভিন্নধর্মী" অবজেক্ট রয়েছে যদিও তারা একক সুপারক্লাসের সাবক্লাস হতে পারে। জাভা পয়েন্ট অফ ভিউ থেকে আপনি ক্লাস (বা ইন্টারফেস) সংজ্ঞাটি সঠিকভাবে পেতে পারেন। অন্যান্য ভাষার জন্য (এলআইএসপি, পাইথন ইত্যাদি) সমস্ত ঘোষণাগুলি সঠিকভাবে লাভ করার কোনও সুবিধা নেই, কারণ বাস্তবায়নের বাস্তবায়নের পার্থক্য নেই।
এস .লট

2

কার্যকরী ভাষায় (লিস্পের মতো), আপনি তালিকার কোনও নির্দিষ্ট উপাদানের কী হয় তা নির্ধারণ করতে প্যাটার্ন মিল ব্যবহার করেন। সি # এর সমতুল্য যদি এর একটি শৃঙ্খল হয় ... অন্য বিবৃতিতে যে কোনও উপাদানটির প্রকারটি পরীক্ষা করে এবং তার উপর ভিত্তি করে একটি ক্রিয়াকলাপ সম্পাদন করে। বলা বাহুল্য, ফাংশনাল প্যাটার্ন মিলটি রানটাইম টাইপ চেকিংয়ের চেয়ে বেশি দক্ষ।

পলিমারফিজম ব্যবহার করা প্যাটার্ন মিলের আরও ঘনিষ্ঠ মিল match তা হল, তালিকার অবজেক্টগুলি একটি নির্দিষ্ট ইন্টারফেসের সাথে মিলে যায় এবং প্রতিটি বস্তুর জন্য সেই ইন্টারফেসে একটি ফাংশন কল করে। আরেকটি বিকল্প হ'ল ওভারলোডেড পদ্ধতিগুলির একটি সিরিজ সরবরাহ করা যা কোনও নির্দিষ্ট বস্তুর প্রকারকে প্যারামিটার হিসাবে গ্রহণ করে। ডিফল্ট পদ্ধতি অবজেক্টটিকে তার প্যারামিটার হিসাবে গ্রহণ করে।

public class ListVisitor
{
  public void DoSomething(IEnumerable<dynamic> list)
  {
    foreach(dynamic obj in list)
    {
       DoSomething(obj);
    }
  }

  public void DoSomething(SomeClass obj)
  {
    //do something with SomeClass
  }

  public void DoSomething(AnotherClass obj)
  {
    //do something with AnotherClass
  }

  public void DoSomething(Object obj)
  {
    //do something with everything els
  }
}

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

ফ্লিপ সাইডটি প্রত্যেককে বার্তাটির জন্য নিবন্ধিত করার জন্য অবহিত করছে (উদাহরণস্বরূপ ইভেন্ট এমগ্রিগেটর প্যাটার্নটি সাধারণত এমভিভিএম প্যাটার্নে ভিউমোডেলগুলির looseিলে coupালা সংযোগের জন্য ব্যবহৃত হয়)। আমি নিম্নলিখিত নির্মাণ ব্যবহার

IDictionary<Type, List<Object>>

অভিধানে যুক্ত করার একমাত্র উপায় একটি ফাংশন

Register<T>(Action<T> handler)

(এবং অবজেক্টটি হ্যান্ডলারের পাসের ক্ষেত্রে আসলে একটি WeakReferences)। সুতরাং এখানে তালিকাটি <অবজেক্ট> ব্যবহার করার জন্য আমি এখানে রয়েছি কারণ সংকলনের সময়, আমি জানি না যে বন্ধ প্রকারটি কী হবে। রানটাইমে তবে আমি প্রয়োগ করতে পারি যে এটি সেই ধরণের হবে যা অভিধানের মূল কী। আমি যখন ইভেন্টটি কল করতে চাই তখন ফায়ার করতে চাই

Send<T>(T message)

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


প্যাটার্ন ম্যাচিংয়ের সাথে, কেসগুলি মিলিত হয় (সাধারণত - কমপক্ষে এমএল এবং হাস্কেলের মধ্যে) মেলানো ডেটা টাইপের ঘোষণার মাধ্যমে পাথর স্থাপন করে। এই জাতীয় ধরণের তালিকাগুলি ভিন্ন ভিন্ন নয়।

আমি এমএল এবং হাস্কেল সম্পর্কে নিশ্চিত নই তবে এরলং যে কোনও অর্থের সাথে ম্যাচ করতে পারে, যদি আপনি অন্য কোনও ম্যাচ সন্তুষ্ট না হওয়ায় এখানে পৌঁছে থাকেন তবে এটি করুন।
মাইকেল ব্রাউন

@ মাইক্রব্রাউন - এটি দুর্দান্ত তবে কোনওটি ভিন্নজাতীয় তালিকা ব্যবহার করবে এবং সর্বদা তালিকার সাথে কাজ করবে না তা কভার করে না <
লিডেমিক

4
সি # তে, ওভারলোডগুলি সংকলনের সময়ে সমাধান করা হয় । সুতরাং, আপনার উদাহরণ কোডটি সর্বদা কল করবে DoSomething(Object)(অন্তত লুপটি ব্যবহার objectকরার সময় foreach; dynamicসম্পূর্ণ আলাদা জিনিস thing
হেইনজি

@ হেইনজি, আপনি ঠিক বলেছেন ... আমি আজ ঘুম পাচ্ছি: পি স্থির
মাইকেল ব্রাউন

0

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

আমার অভিজ্ঞতায় ফাইল, নেটওয়ার্ক সকেট ইত্যাদির মাধ্যমে কাঁচা বাইটগুলি ব্যবহার করে আপনি প্রায়শই এই জাতীয় সমস্যায় পড়েন।

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

এই রেকর্ডগুলি কোথায় রাখা যেতে পারে? স্বজ্ঞাতভাবে, আপনি যা চান তা হ'ল কিছু Dictionary<WorkId, Future<TValue>>, তবে এটি আপনাকে পুরো সিস্টেমে কেবলমাত্র এক ধরণের ফিউচার পরিচালনা করতে সীমাবদ্ধ করে। আরও উপযুক্ত প্রকারটি হ'ল Dictionary<WorkId, Future<dynamic>>, যেহেতু কর্মী ভবিষ্যতের উপর চাপ দেয় তখন উপযুক্ত টাইপ করতে পারে।

দ্রষ্টব্য : এই উদাহরণটি হ্যাস্কেল বিশ্ব থেকে এসেছে যেখানে আমাদের সাবটাইপিং নেই। C # তে এই নির্দিষ্ট উদাহরণের জন্য আরও কিছু মুশকিল সমাধান থাকলে আমি অবাক হব না, তবে আশা করি এটি এখনও চিত্রণযোগ্য।


0

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.