ইন্টারফেস কার্যকর করা যখন আপনার কোনও বৈশিষ্ট্যের প্রয়োজন হয় না

31

অনেকটাই অকপট. আমি একটি ইন্টারফেস বাস্তবায়ন করছি, তবে এমন একটি সম্পত্তি রয়েছে যা এই শ্রেণীর জন্য অপ্রয়োজনীয় এবং বাস্তবে এটি ব্যবহার করা উচিত নয়। আমার প্রাথমিক ধারণাটি ছিল ঠিক এমন কিছু করা:

int IFoo.Bar
{
    get { raise new NotImplementedException(); }
}

আমি মনে করি, এই প্রতি কোনও ভুল নেই, তবে এটি "সঠিক" বোধ করে না। এর আগে অন্য কেউ কি এরকম পরিস্থিতি দেখে এসেছিল? যদি তা হয় তবে কীভাবে আপনি এর কাছে গিয়েছিলেন?

c# design interfaces implementations

— ক্রিস প্র্যাট
সূত্র

1

আমি অস্পষ্টভাবে C # তে কিছু আধা-সাধারণভাবে ব্যবহৃত ক্লাস মনে করি যা একটি ইন্টারফেস প্রয়োগ করে তবে ডকুমেন্টেশনে স্পষ্ট করে বলে যে একটি নির্দিষ্ট পদ্ধতি প্রয়োগ করা হয়নি। আমি এটি খুঁজে পেতে পারি কিনা তা দেখার চেষ্টা করব।

— ম্যাজি জাই

আমি অবশ্যই তা দেখতে আগ্রহী, যদি আপনি এটি পেতে পারেন।

— ক্রিস প্র্যাট

23

নেট এর লাইব্রেরিতে আমি এর একাধিক কেস চিহ্নিত করতে পারি - এবং তারা সমস্ত খারাপের ভুল হিসাবে স্বীকৃত । এটি লিসকোভ সাবস্টিটিউশন নীতিমালার একটি প্রতীকী এবং সাধারণ লঙ্ঘন - এলএসপি লঙ্ঘন না করার কারণগুলি আমার

— উত্তরটিতে

3

আপনার কি এই নির্দিষ্ট ইন্টারফেসটি বাস্তবায়নের প্রয়োজন, বা আপনি একটি সুপারইন্টারফেস চালু করতে এবং এটি ব্যবহার করতে পারেন?

— ক্রিস্টোফার শুল্টজ

6

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

— সেবাস্তিয়ান রেডল

51

লোকেরা কীভাবে লিসকভ সাবটিউটিউশন নীতি লঙ্ঘন করার সিদ্ধান্ত নেয় তার একটি শাস্ত্রীয় উদাহরণ। আমি দৃ strongly়ভাবে এটিকে নিরুৎসাহিত করি তবে সম্ভবত এটির ভিন্ন সমাধানটিকে উত্সাহিত করব:

সম্ভবত আপনি যে ক্লাসটি লিখছেন তা ইন্টারফেসের সমস্ত সদস্যের ব্যবহার না থাকলে ইন্টারফেসের কার্যকারিতা সরবরাহ করে না।
বিকল্পভাবে, সেই ইন্টারফেসটি একাধিক কাজ করতে পারে এবং ইন্টারফেস বিভাজন নীতি অনুযায়ী পৃথক করা যেতে পারে।

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

এখানে উইকিপিডিয়া থেকে কয়েকটি দ্রুত বিট দেওয়া হয়েছে:

লিসকভ সাবস্টিটিউশন নীতিটি কেবল "পূর্ব-শর্তগুলি শক্তিশালী করবেন না, এবং পোস্ট-শর্তগুলি দুর্বল করবেন না" হিসাবে তৈরি করা যেতে পারে।

আরও আনুষ্ঠানিকভাবে, লিসকভ সাবস্টিটিউশন নীতি (এলএসপি) হ'ল সাব-টাইপিং সম্পর্কের একটি বিশেষ সংজ্ঞা, যাকে বলা হয় (শক্তিশালী) আচরণগত সাব-টাইপিং, এটি প্রথমে বারবারা লিসকভ ১৯৮7 সালে একটি ডেটা অ্যাবস্ট্রাকশন এবং হায়ারার্কি শিরোনামে একটি সম্মেলনের মূল বক্তৃতায় প্রবর্তন করেছিলেন। এটি নিছক সিনট্যাক্টিক সম্পর্কের পরিবর্তে একটি শব্দার্থক কারণ এটি একটি শ্রেণিবিন্যাসের ধরণের শব্দার্থক আন্তঃব্যবযোগিতার গ্যারান্টি দিতে চায় , [...]

একই চুক্তির বিভিন্ন বাস্তবায়নের মধ্যে শব্দার্থক আন্তঃব্যবযোগিতা এবং বিকল্প ব্যবস্থার জন্য - আপনার সকলকে একই আচরণের প্রতিশ্রুতিবদ্ধ হওয়া প্রয়োজন।

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

ইন্টারফেস-বিভাজন নীতি (আইএসপি) বলেছে যে কোনও ক্লায়েন্টকে যে পদ্ধতিগুলি ব্যবহার না করে তার উপর নির্ভর করতে বাধ্য করা উচিত [[1] আইএসপি ইন্টারফেসগুলি বিভক্ত করে তোলে যা খুব ছোট এবং আরও নির্দিষ্ট একটিতে খুব বড় হয় যাতে ক্লায়েন্টদের কেবল তাদের আগ্রহী পদ্ধতিগুলি সম্পর্কে জানতে হবে।

— জিমি হোফা
সূত্র

একেবারে। প্রথম কারণেই সম্ভবত এটি আমার কাছে সঠিক মনে হয়নি। কখনও কখনও আপনার কেবল একটি মৃদু অনুস্মারক প্রয়োজন যে আপনি বোকা কিছু করছেন। ধন্যবাদ।

— ক্রিস প্র্যাট

@ ক্রিসপ্রট এটি তৈরি করা একটি সত্যই সাধারণ ভুল, এ কারণেই আনুষ্ঠানিকতা মূল্যবান হতে পারে - শ্রেণিবদ্ধকরণ কোডের গন্ধগুলি তাদের দ্রুত সনাক্ত করতে এবং পূর্বে ব্যবহৃত সমাধানগুলি পুনরায় স্মরণ করতে সহায়তা করে।

— জিমি হোফা

4

আমার অবস্থা ভাল লাগছে, যদি এই আপনার অবস্থা হয়।

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

_{দাবি অস্বীকার: সঠিকভাবে করতে এর জন্য একাধিক উত্তরাধিকার প্রয়োজন এবং সি # এটি সমর্থন করে কিনা তা আমার কোনও ধারণা নেই।}

— মনিকার সাথে লাইটনেস রেস
সূত্র

6

সি # ক্লাসের একাধিক উত্তরাধিকারকে সমর্থন করে না, তবে এটি ইন্টারফেসের জন্য এটি সমর্থন করে।

— mgw854

2

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

— ক্রিস প্র্যাট

@ ক্রিসপ্র্যাট: হ্যাঁ

— মনিকার সাথে লাইটনেস রেস

4

আমি এই পরিস্থিতি পেরিয়ে এসেছি। আসলে অন্য কোথাও ছাত্রলীগের যেমন উদাহরণ রয়েছে ... আমি আরও ভাল উদাহরণ দেওয়ার চেষ্টা করব এবং কিছু যুক্তি সরবরাহ করার চেষ্টা করব:

আপনার যদি ইতিমধ্যে শিপানো ইন্টারফেস থাকে যা আপনি সামঞ্জস্যের কারণে এবং ...

ইন্টারফেসে এমন সদস্য রয়েছে যা অপ্রচলিত বা বিচ্ছিন্ন। উদাহরণস্বরূপ BlockingCollection<T>.ICollection.SyncRoot(অন্যদের মধ্যে) যদিও ICollection.SyncRootপ্রতি সেচ অপ্রচলিত নয়, এটি নিক্ষেপ করবে NotSupportedException।
ইন্টারফেসে এমন সদস্য রয়েছে যা ডকুমেন্ট করা alচ্ছিক হতে পারে এবং প্রয়োগটি ব্যতিক্রম ছুঁড়ে দিতে পারে। উদাহরণস্বরূপ এমএসডিএন এ সম্পর্কে IEnumerator.Resetবলে:

রিসেট পদ্ধতিটি COM আন্তঃব্যবহারের জন্য সরবরাহ করা হয়। এটি কার্যকরভাবে প্রয়োগ করার প্রয়োজন নেই; পরিবর্তে, প্রয়োগকারী কেবল একটি নটসোপোর্টড এক্সসেপশন নিক্ষেপ করতে পারে।

ইন্টারফেসের ডিজাইনের ভুল করে, এটি প্রথম স্থানে একাধিক ইন্টারফেস হওয়া উচিত ছিল। বিসিএলে কনটেইনারগুলির কেবলমাত্র পড়ুন সংস্করণগুলি প্রয়োগ করা এটি সাধারণ প্যাটার্ন NotSupportedException। আমি নিজেই এটি করেছি, এটি এখন প্রত্যাশিত ... আমি ICollection<T>.IsReadOnlyফিরে আসি trueযাতে আপনি তাদের অ্যাপটি বলতে পারেন। সঠিক নকশাটি ইন্টারফেসের একটি পাঠযোগ্য সংস্করণ ছিল এবং তারপরে পুরো ইন্টারফেসটি উত্তরাধিকার সূত্রে প্রাপ্ত।
ব্যবহারের মতো আরও ভাল ইন্টারফেস নেই। উদাহরণস্বরূপ, আমার কাছে একটি শ্রেণি রয়েছে যা আপনাকে সূচী দ্বারা আইটেমগুলি অ্যাক্সেস করার অনুমতি দেয়, এটিতে কোনও আইটেম রয়েছে কিনা তা যাচাই করে নিন এবং এর সূচীতে এটির কিছু আকার রয়েছে, আপনি এটি একটি অ্যারেতে অনুলিপি করতে পারেন ... এটি একটি কাজ বলে মনে হয় IList<T>তবে আমার ক্লাসে আছে একটি নির্দিষ্ট আকার এবং এটি যোগ করা বা সরানো সমর্থন করে না, সুতরাং এটি তালিকার চেয়ে অ্যারের মতো আরও কাজ করে। কিন্তু আছে কোন IArray<T>ছাত্রলীগের মধ্যে ।
ইন্টারফেসটি এমন এক এপিআই-র অন্তর্গত যা একাধিক প্ল্যাটফর্মগুলিতে রুদ্ধ হয় এবং নির্দিষ্ট প্ল্যাটফর্মের প্রয়োগে এর কিছু অংশ সমর্থিত হয় না। আদর্শভাবে এটি সনাক্ত করার কিছু উপায় থাকবে, যাতে পোর্টেবল কোড যেমন এপিআই ব্যবহার করে তবে সেই অংশগুলিকে কল করা বা না করাই সিদ্ধান্ত নিতে পারে ... তবে আপনি যদি তাদের কল করেন তবে এটি পাওয়া সম্পূর্ণ উপযুক্ত NotSupportedException। এটি বিশেষত সত্য, যদি এটি কোনও নতুন প্ল্যাটফর্মের একটি বন্দর হয় যা মূল নকশায় আগেই দেখা যায়নি।

এটিকে কেন সমর্থন করা হচ্ছে না তা বিবেচনা করুন?

কখনও কখনও InvalidOperationExceptionএকটি ভাল বিকল্প। উদাহরণস্বরূপ, ক্লাসে পলিমারফিজম যুক্ত করার আরও একটি উপায় হ'ল অভ্যন্তরীণ ইন্টারফেসের বিভিন্ন বাস্তবায়ন এবং আপনার কোডটি ক্লাসের কনস্ট্রাক্টরের প্রদত্ত পরামিতিগুলির উপর নির্ভর করে কোনটি ইনস্ট্যান্ট করতে হবে তা বেছে নিচ্ছে। [যদি আপনি জানেন যে বিকল্পগুলির সেটটি স্থির হয়ে গেছে এবং আপনি তৃতীয় পক্ষের ক্লাসগুলি নির্ভরতা ইনজেকশন দ্বারা প্রবর্তন করতে চান না তবে আপনি এটি সূক্ষ্মভাবে দরকারী ]] থ্রেডলোকালকে ব্যাকপোর্ট করতে আমি এটি করেছি কারণ ট্র্যাকিং এবং নন-ট্র্যাকিং বাস্তবায়ন খুব দূরে অ্যাপ্লিকেশন, এবং ThreadLocal.Valuesনন-ট্র্যাকিং বাস্তবায়নটিকে কী প্রভাব ফেলবে?InvalidOperationExceptionএমনকি, এটি বস্তুর অবস্থার উপর নির্ভর করে না। এক্ষেত্রে আমি নিজেই ক্লাসটি চালু করলাম এবং আমি জানতাম যে এই পদ্ধতিটি কেবল একটি ব্যতিক্রম ছুঁড়ে দিয়ে বাস্তবায়ন করতে হয়েছিল।

কখনও কখনও একটি ডিফল্ট মান বোঝায়। ICollection<T>.IsReadOnlyউপরে উল্লিখিত উদাহরণস্বরূপ , কেসটি নির্ভর করে কেবল ´true´ বা ´false´ ফিরিয়ে দেওয়া অর্থপূর্ণ makes সুতরাং ... এর শব্দার্থবিজ্ঞান কি IFoo.Bar? ফিরে আসতে কিছু বুদ্ধিমান ডিফল্ট মান থাকতে পারে।

সংযোজন: আপনি যদি ইন্টারফেসের নিয়ন্ত্রণে থাকেন (এবং আপনার পক্ষে এটির সাথে সামঞ্জস্যের জন্য থাকার দরকার নেই) এমন কোনও ঘটনা ঘটবে না যেখানে আপনাকে ফেলে দিতে হবে NotSupportedException। যদিও, আপনার ক্ষেত্রে যথাযথ উপযুক্ত হওয়ার জন্য আপনাকে ইন্টারফেসটি দুটি বা আরও বেশি ছোট ইন্টারফেসে বিভক্ত করতে হতে পারে, যা চরম পরিস্থিতিতে "দূষণ" হতে পারে।

— Theraot
সূত্র

0

এর আগে অন্য কেউ কি এরকম পরিস্থিতি দেখে এসেছিল?

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

* মাইক্রোসফ্ট যেমন ব্যবহার করেছে তেমনি "লুকানো" শব্দের কঠোর অর্থে পদ্ধতিগুলি "আড়াল" করে না । তবে আমি এই উদাহরণে আরও ভাল শব্দ জানি না।

— user2023861
সূত্র

... যা ভয়ানক।

— মনিকার সাথে লাইটনেস রেস

ডাউনটা কেন?

— ব্যবহারকারী 2023861

2

সম্ভবত আপনি প্রশ্নের উত্তর না দেওয়ার কারণ। ইশ। প্রকার, রকম.

— মনিকার সাথে লাইটনেস রেস

@ লাইটনেসেসেসিনআরবিট, আমি আরও উত্তর পরিষ্কার করার জন্য আমার উত্তর আপডেট করেছি। আমি আশা করি এটি ওপিকে সহায়তা করে।

— ব্যবহারকারী 2023861

2

দেখে মনে হচ্ছে এটি আমার উত্তর দেয়। এটি একটি ভাল বা খারাপ ধারণা হতে পারে এই বিষয়টি প্রশ্নের ক্ষেত্রের মধ্যে মনে হচ্ছে না তবে এটি উত্তরগুলি ইঙ্গিত করার জন্য এখনও কার্যকর হতে পারে।

— এলিসেডিল

-6

আপনি সর্বদা কেবল সৌম্য মান বা ডিফল্ট মান বাস্তবায়ন করতে এবং ফিরিয়ে দিতে পারেন। সর্বোপরি এটি কেবল একটি সম্পত্তি। এটি 0 (ইন্টের ডিফল্ট সম্পত্তি) ফিরে আসতে পারে বা আপনার বাস্তবায়নে যে কোনও মান উপলব্ধি করে (int.MinValue, int.MaxValue, 1, 42, ইত্যাদি ...)

//We don't officially implement this property
int IFoo.Bar
{
     { get; }
}

একটি ব্যতিক্রম নিক্ষেপ খারাপ ফর্ম মত মনে হচ্ছে।

— জন রায়নার
সূত্র

2

কেন? ভুল ডেটা ফেরানো কীভাবে আরও ভাল?

— মনিকার সাথে লাইটনেস রেস

1

এটি এলএসপিকে ভেঙে দেয়: এর কারণ ব্যাখ্যা করার জন্য জিমি হোফার উত্তর দেখুন।

5

যদি কোনও সঠিক সঠিক ফেরতের মান না থাকে তবে একটি ভুল মান ফেরানোর চেয়ে একটি ব্যতিক্রম ছুঁড়ে ফেলা ভাল। আপনি যা করেন তা নির্বিশেষে আপনার প্রোগ্রামটি যদি ভুলভাবে এই সম্পত্তিটিকে ডাকে তবে আপনার প্রোগ্রামটি খারাপ হতে চলেছে। তবে আপনি যদি কোনও ব্যতিক্রম ছুঁড়েন তবে এটি কেন ত্রুটিযুক্ত তা স্পষ্ট হবে ।

— ট্যানার সোয়েট

আপনার এখন ইন্টারফেসটি প্রয়োগ করা হলে মানটি কীভাবে ভুল হবে তা আমি এখন করি না! এটি আপনার বাস্তবায়ন, এটি আপনি যা চান তা হতে পারে।

— জন রায়নোর

সংকলনের সময় যদি সঠিক মানটি অজানা ছিল?

— অ্যান্ডি