জাভা সংগ্রহ ফ্রেমওয়ার্ক ইন্টারফেসে অসমর্থিত অপারেশন এক্সসেপশন

Question

জাভা সংগ্রহ ফ্রেমওয়ার্কটি দেখে, আমি লক্ষ্য করেছি বেশ কয়েকটি ইন্টারফেসের মন্তব্য রয়েছে (optional operation)। এই পদ্ধতিগুলি ক্লাস বাস্তবায়নের অনুমতি দেয় UnsupportedOperationExceptionযদি তারা কেবল সেই পদ্ধতিটি প্রয়োগ করতে না চায়।

এর উদাহরণ হ'ল addAllপদ্ধতিতে Set Interface।

এখন, এই সিরিজের প্রশ্নের বিবরণ অনুসারে, ইন্টারফেসগুলি ব্যবহারটি কী আশা করতে পারে তার একটি সংজ্ঞায়িত চুক্তি।

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

এবং

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

এবং

আমি মনে করি ইন্টারফেস ভিত্তিক পদ্ধতির উল্লেখযোগ্যভাবে সুন্দর। তারপরে আপনি আপনার নির্ভরতাগুলি সুন্দরভাবে উপহাস করতে পারেন এবং সবকিছুই মূলত কম শক্ত করে মিলিত হয়।

একটি ইন্টারফেসের বিন্দুটি কী?

ইন্টারফেস কি?

ইন্টারফেস + এক্সটেনশন (মিক্সিন) বনাম বেস ক্লাস

ইন্টারফেসের উদ্দেশ্য একটি চুক্তি সংজ্ঞায়িত করা এবং আপনার নির্ভরতাগুলি আলগাভাবে যুগল করে তোলা, এমন কোনও পদ্ধতিতে কী একধরণের UnsupportedOperationExceptionপরাজয়কে উদ্দেশ্য হিসাবে পরাভূত করে না? এর অর্থ আমি আর পাস করতে পারি না Setএবং কেবল ব্যবহার করতে পারি addAll। বরং আমাকে জানতে হবে যে Setআমার কী বাস্তবায়ন পাস হয়েছে, তাই আমি জানতে পারি আমি ব্যবহার করতে পারি কি addAllনা। এটা আমার কাছে বেশ মূল্যহীন বলে মনে হচ্ছে।

তাহলে কি লাভ UnsupportedOperationException? এটি কি কেবল উত্তরাধিকারের কোডটি তৈরি করছে এবং তাদের ইন্টারফেসগুলি পরিষ্কার করা দরকার? বা এর কি আরও সংবেদনশীল উদ্দেশ্য রয়েছে যা আমি মিস করছি?

Comments

আপনি কোন জেআরই ব্যবহার করছেন তা আমি জানি না, তবে আমার ওরাকল সংস্করণ 8 এর addAllমধ্যে সংজ্ঞা দেওয়া হয়নি HashSet। এটি ডিফল্ট বাস্তবায়নে পিছিয়ে যায় AbstractCollectionযা সম্ভবত অবশ্যই ছুঁড়ে নাUnsupportedOperationException ।

@ সুমন আপনি ঠিক বলেছেন আমি দস্তাবেজগুলি মিস করেছি। আমি আমার প্রশ্ন সম্পাদনা করব।

— মিররফেট

আমি Eclipse শুরু করতে এবং উত্স কোডটি দেখতে চাই, কোড রেফারেন্সগুলি এবং সংজ্ঞাগুলির চারপাশে বাউন্স করে আমার এটি ঠিক আছে কিনা তা নিশ্চিত করতে। যতক্ষণ না জেআরই এর সাথে যুক্ত থাকে তত src.zipদুর্দান্ত কাজ করে। এটি জেআরই মাঝে মাঝে ঠিক কী কোডটি চালাচ্ছে তা জাভাডকের কাছে স্থগিত করে না যা কিছুটা ভার্বোস হতে পারে তা জানতে সহায়তা করে।

Answer 1

নিম্নলিখিত ইন্টারফেস দেখুন:

• সংগ্রহ
• তালিকা
• মানচিত্র
• সেট

এই ইন্টারফেসগুলি সমস্ত পরিবর্তনের পদ্ধতিগুলি alচ্ছিক হিসাবে ঘোষণা করে । এটি স্পষ্টতই ডকুমেন্ট করছে যে সংগ্রহগুলি শ্রেণি অপরিবর্তনীয় এমন ইন্টারফেসগুলির বাস্তবায়ন ফিরিয়ে দিতে সক্ষম: অর্থাৎ thoseচ্ছিক মিউটেশন অপারেশনগুলি ব্যর্থ হওয়ার গ্যারান্টিযুক্ত। তবে জাভাডকের চুক্তি অনুসারে, সেই ইন্টারফেসগুলির সমস্ত বাস্তবায়নকে অবশ্যই পড়ার ক্রিয়াকলাপের অনুমতি দিতে হবে। এর মধ্যে "স্বাভাবিক" বাস্তবায়ন যেমন অভ্যন্তরীন HashSetএবং LinkedListঅপরিবর্তনীয় মোড়কে অন্তর্ভুক্ত Collections।

কিউ ইন্টারফেসের সাথে বৈপরীত্য:

• Deque
• কিউ

এই ইন্টারফেসটি কোনও alচ্ছিক ক্রিয়াকলাপ নির্দিষ্ট করে না : সংজ্ঞা অনুসারে একটি সারি একটি ফিফোর পদ্ধতিতে উপাদান সরবরাহ এবং পোল করার জন্য ডিজাইন করা হয়েছে। একটি অপরিবর্তনীয় সারি চাকা ছাড়াই গাড়ি হিসাবে প্রায় দরকারী।

---

একটি সাধারণ ধারণা যা বারবার আসে তা হ'ল একটি উত্তরাধিকারের শ্রেণিবদ্ধতা যা উভয়ই পরিবর্তনযোগ্য এবং পরিবর্তনযোগ্য অবজেক্ট has যাইহোক, এই সবেরই ঘাটতি রয়েছে। জটিলতা সমস্যাটি আসলে সমস্যার সমাধান না করেই জলাবদ্ধতায় .োকে।

• একটি প্রকল্পিত Setপঠিত অপারেশন হতে পারে, এবং একটি subinterface MutableSetলেখার অপারেশন ফেলতে পারে। লিসকভ আমাদের জানান যে এর MutableSetপরে যে কোনও প্রয়োজনের মধ্যে একটি স্থান দেওয়া যেতে পারে Set। প্রথমে এটি ঠিক শোনাচ্ছে, তবে এমন একটি পদ্ধতি বিবেচনা করুন যা আশা করে যে অন্তর্নিহিত সেটটি পড়ার সময় সংশোধন করা হবে না: দুটি থ্রেডের জন্য একই সেটটি ব্যবহার করা সম্ভব হবে এবং সেটটি পরিবর্তিত না হওয়ার আক্রমণকারীকে লঙ্ঘন করবে। এটি সমস্যার কারণ হতে পারে উদাহরণস্বরূপ যদি কোনও পদ্ধতি সেট থেকে দুটি উপাদান একবারে পড়ে এবং এটি প্রথমবার থাকে তবে দ্বিতীয়বার নয়।

• Setএর পরিবর্তে ক্লাস বাস্তবায়নের জন্য ব্যবহৃত সাবিনটারফেসগুলি MutableSetএবং পরিবর্তে কোনও সরাসরি বাস্তবায়ন থাকতে পারে না ImmutableSet। এটি উপরের মতো একই সমস্যা রয়েছে: শ্রেণিবিন্যাসের কোনও এক পর্যায়ে, একটি ইন্টারফেসের বিরোধী আক্রমণকারী রয়েছে। একটি বলে "এই সেটটি অবশ্যই পরিবর্তনযোগ্য হতে হবে" এবং অন্যটি বলেছেন "এই সেটটি পরিবর্তন হতে পারে না।"

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

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

---

সম্পর্কিত পড়া: জাভা 8 কেন অপরিবর্তনীয় সংগ্রহগুলি অন্তর্ভুক্ত করে না?

Comments

তবে যদি পদ্ধতিগুলি alচ্ছিক হয় তবে তাদের ইন্টারফেসে কী জায়গা থাকবে? Thereচ্ছিক পদ্ধতিগুলি সহ আলাদা আলাদা ইন্টারফেস থাকা উচিত নয় MutableCollection?

— মিররফেটে

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

অপরিবর্তনীয় সারি সম্পর্কে এটি বিস্তৃত বিবৃতি। এই সমস্যাটি সমাধান করতে আমি কয়েক দিন আগে একটি ব্যবহার করেছি ।

— কার্ল বিলেফেল্ট

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

— মিররফেট

@ মিররফেট আমার সাম্প্রতিক সম্পাদনাটি পড়ুন।

Answer 2

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

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

Comments

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

— মিররফেটে