কোনও ইভেন্ট প্রেরককে কি সর্বদা জেনেরিক অবজেক্ট হওয়া উচিত?


10

সি # তে ইভেন্টগুলি প্রোগ্রাম করার সময়, আকারে একটি প্রতিনিধি তৈরি করার পরামর্শ দেওয়া হয়:

delegate XEventHandler(object sender, XEventArgs e);

আমার প্রশ্ন, প্রতিনিধি প্রথম যুক্তি রয়েছে object sender। এটি কি সবসময় জেনেরিক হতে হবে object? প্রেরকের প্রকারের ফলে objectসর্বদা এর অনুরূপ কোডের ফলাফল হয়।

val = ((ConcreteType)sender).Property;

বা আরও ভার্জোজ,

ConcreteType obj = sender as ConcreteType
if (obj != null) { ... }

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

যদি প্রেরকের শ্রেণি সর্বদা পরিচিত হয় (অন্তত একটি বিমূর্ত শ্রেণি হিসাবে)? উদাহরণস্বরূপ, যদি আমি ListChangedএকটি বিমূর্ত Listশ্রেণিতে কোনও ইভেন্ট বাস্তবায়ন করি এবং অন্য শ্রেণিগুলি যদি এর উত্তরাধিকারী হতে চলেছে (যেমন LinkedList, ArrayList), তবে প্রকারের প্রেরকের সাথে আমার প্রতিনিধিকে সংজ্ঞায়িত করা কি সব ঠিক আছে List?

delegate ListChangedEventHander(List sender, ListChangedEventArgs e);

বা, প্রচলিত object senderআরো নির্দিষ্ট ধরণের পরিবর্তনের একটি নেতিবাচক প্রভাব আছে ?

উত্তর:


10

এই মুহুর্তে, এটি বেশিরভাগই একটি (বেশ শক্তিশালী) সম্মেলন। এটি হ'ল অদ্ভুত হবে যদি আপনি এমন কোনও লাইব্রেরি লিখেন যা সেই সম্মেলনটি অনুসরণ করে না।

ইভেন্ট ডিজাইন নির্দেশিকা বলে,

DO ব্যবহার objectইভেন্ট হ্যান্ডলার এর প্রথম প্যারামিটার ধরণ, এবং একে ডাকতে sender

যাইহোক, আপনি লক্ষ রাখতে পারেন যে বর্তমান নির্দেশিকা আপনার নিজের কাস্টম প্রতিনিধিদের ইভেন্টগুলির জন্য সংজ্ঞায়িত করবেন না EventHandler<T>, তবে আপনি যদি পারেন তবে পরিবর্তে ব্যবহার করুন।

নকশা হিসাবে, আমি অনুমান করব যে এটি ইভেন্ট হ্যান্ডলারদের পুনঃব্যবহারকেও উত্সাহিত করে, এমনকি ইভেন্টের মূল ডিজাইনার দ্বারা পূর্বসূচীতে দেখা যায়নি এমন প্রসঙ্গেও।


2
উঘহ ... কেবলমাত্র মাইক্রোসফ্ট প্রত্যেকের জন্য প্রযোজ্য হওয়ার জন্য তাদের নির্দেশিকা যথেষ্ট পরিমাণে জেনারেল করার সিদ্ধান্ত নিয়েছে, এর অর্থ এই নয় যে প্রত্যেকের পক্ষে তাদের নির্দেশিকাগুলি অনুসরণ করা ভাল ধারণা। অদ্ভুত সম্ভাবনা খুব সম্ভবত যে "অন্যান্য প্রত্যেকে" কোডগুলি লিখন করে না যা লক্ষ লক্ষ অন্যান্য বিকাশকারী ব্যবহার করে। আপনার সরবরাহিত লিঙ্কটি থেকে আমি প্রায় 2/3 এর প্রস্তাবনাগুলিকে সঙ্কুচিত করেছিলাম।
ডাঙ্ক

আপনাকে সত্যি বলতে, এই "গাইডলাইন" কমবেশি উইন্ডোজ এপিআইয়ের হাঙ্গেরিয়ান স্বরলিপি অনুভব করে। উজ্জ্বল কেউ এটি সত্যিই ভাল কারণে শুরু করেছিলেন এবং তারপরে অন্য প্রত্যেকে একে অপব্যবহার করতে শুরু করেছিলেন। যখন কোনও গাইডলাইন থাকে তখন সেই গাইডলাইনটির পিছনে আরও ভাল কারণ থাকতে পারে। এবং আমি কী মনে করি এই গাইডলাইনটির কারণ হ'ল System.Windows.Formsনাম স্থানটি সেই জায়গা যেখানে ইভেন্টগুলি সবচেয়ে বেশি ব্যবহৃত হয় এবং এটি Clickইভেন্টটির Buttonবা এ এর সাবস্ক্রাইব করার বিষয়টি বোধগম্য হয়েছিল CheckBox। এভাবে প্রেরক প্রয়োজন জেনেরিক যাবে। ...
সাম্পাথ্রিসিস

... তবে যখন এটি অন্যান্য, আরও সুনির্দিষ্ট, কার্যকারিতার ক্ষেত্রগুলি অন্তর্ভুক্ত থাকে তখন প্রেরকের জেনেরিক শ্রেণি হওয়ার দরকার পড়তে পারে না। আমার ক্লাসের শ্রেণিবিন্যাসের উদাহরণটি আবার দেখুন List
সাম্পাথিস্রিস

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

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

0

প্রস্তাবনার কারণ হ'ল এটি ভবিষ্যতের পরিবর্তনের জন্য মঞ্জুরি দেয় যা প্রয়োজনীয় কোডগুলি এবং বিশেষত পাবলিক ইন্টারফেসের পরিবর্তন প্রয়োজন হয় না।

ইভেন্ট সিস্টেমটি নিজেই এখনও "ভিবি 6"-স্টাইল ইভেন্টগুলির জন্য ব্যবহার করা যেতে পারে, তবে আপনাকে যদি স্বাক্ষরটি পরিবর্তন করতে হয় তবে (বা আরও খারাপ: একই ইভেন্টগুলির নতুন সংস্করণ তৈরি করুন) আপনাকে সমস্ত বিদ্যমান গ্রাহককে পরিবর্তন করতে হবে। প্রস্তাবিত পদ্ধতির সাথে, যতক্ষণ না নতুন আইটেমগুলি বিদ্যমানগুলির থেকে উত্তরাধিকার সূত্রে পাওয়া যায় ততক্ষণ আপনি বিদ্যমান কোডটি স্থির না করে স্বাক্ষর আপডেট করতে পারেন।

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