জাভা বা সি # তে কেন একাধিক উত্তরাধিকার অনুমোদিত নয়?


115

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


1
শুধু যে নির্দেশ মত হয় অবকাঠামো সেখানে যা এমআই মত C # এর ক্লাসের আচরণ অনুমতি দেয়। এবং অবশ্যই আপনার কাছে স্টেটলেস মিক্সিন (এক্সটেনশন পদ্ধতি ব্যবহার করে) থাকার বিকল্প রয়েছে - রাষ্ট্রবিহীন হওয়া যদিও তারা খুব কার্যকর নয়।
দিমিত্রি নেস্টারুক

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

উত্তর:


143

সংক্ষিপ্ত উত্তরটি হ'ল: কারণ ভাষা ডিজাইনাররা সিদ্ধান্ত নেবেন না।

মূলত, দেখে মনে হয়েছিল যে .NET এবং জাভা উভয় ডিজাইনারই একাধিক উত্তরাধিকারের অনুমতি দেয়নি কারণ তারা যুক্তি দিয়েছিলেন যে এমআই যুক্ত করার কারণে ভাষাগুলিতে খুব বেশি জটিলতা যুক্ত হয়েছে যখন খুব সামান্য সুবিধা দেওয়া হয়েছে

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

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

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

  3. একাধিক বাস্তবায়নের উত্তরাধিকার বাস্তবায়নে অনেক জটিলতা। এই জটিলতা castালাই, লেআউট, প্রেরণ, ক্ষেত্রের অ্যাক্সেস, সিরিয়ালাইজেশন, পরিচয়ের তুলনা, যাচাইযোগ্যতা, প্রতিবিম্ব, জেনারিকস এবং সম্ভবত অন্যান্য অনেক জায়গায় প্রভাব ফেলে।

আপনি এখানে সম্পূর্ণ নিবন্ধ পড়তে পারেন।

জাভা জন্য, আপনি পড়তে পারেন এই নিবন্ধটি :

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

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


10
ভাল তুলনা। আমার মনে হয় এমন দুটি প্ল্যাটফর্মকেই বিবেচনা করে যে চিন্তাধারার প্রক্রিয়াগুলির যথেষ্ট সূচক।
কার্টেনডগ

97

বাস্তবায়নের একাধিক উত্তরাধিকার যা অনুমোদিত নয়।

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

আমি বিশ্বাস করি একে ডাবল হীরার উত্তরাধিকারের সমস্যা বলা হয়।


80
আপনি রাস্তায় মারা যাওয়া কারও মনোরম জলরঙ পান :-)
ড্যান এফ

এটাই কি একমাত্র সমস্যা? আমি মনে করি, আমি নিশ্চিত নই যে সি ++ ভার্চুয়াল কীওয়ার্ড দ্বারা এই সমস্যাটি সমাধান করে, এটি কি সত্য? আমি সি ++ তে ভাল নেই
আব্দুলসত্তার মোহাম্মদ

2
সি ++ এ আপনি যে কোনও বেস ক্লাসের ফাংশনগুলি কল করতে হবে তা নির্ধারণ করতে পারেন বা এটি নিজেই প্রয়োগ করতে পারেন।
দিমিত্রি রাইজনবার্গ

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

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

19

কারণ: জাভা খুব জনপ্রিয় এবং কোড করা সহজ, এর সরলতার কারণে।

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

  1. তারা পয়েন্টার এড়ানো
  2. তারা একাধিক উত্তরাধিকার এড়িয়ে চলেন।

একাধিক উত্তরাধিকার নিয়ে সমস্যা : ডায়মন্ড সমস্যা।

উদাহরণ :

  1. ধরুন যে ক্লাস এ পদ্ধতিতে মজা করছে ()। ক্লাস বি এবং ক্লাস সি ক্লাস এ থেকে প্রাপ্ত
  2. এবং বি এবং সি উভয় শ্রেণিই পদ্ধতি মজাদার () উপেক্ষা করে r
  3. এখন ধরে নিন যে ক্লাস ডি বি এবং সি উভয় শ্রেণীর উত্তরাধিকার সূত্রে প্রাপ্ত (কেবল অনুমান)
  4. ডি ক্লাসের জন্য অবজেক্ট তৈরি করুন
  5. ডি d = নতুন ডি ();
  6. এবং d.fun () অ্যাক্সেস করার চেষ্টা করুন; => এটি ক্লাস বি এর মজা () বা ক্লাস সি এর মজা () বলবে?

এটি হীরা সমস্যার বিদ্যমান অস্পষ্টতা।

এই সমস্যাটি সমাধান করা অসম্ভব নয়, তবে প্রোগ্রামারটি পড়ার সময় এটি আরও বিভ্রান্তি ও জটিলতা তৈরি করে। এটি সমাধান করার চেষ্টা করার চেয়ে বেশি সমস্যা সৃষ্টি করে।

দ্রষ্টব্য : তবে যে কোনও উপায়ে আপনি সর্বদা ইন্টারফেস ব্যবহার করে পরোক্ষভাবে একাধিক উত্তরাধিকার প্রয়োগ করতে পারেন।


1
"তবে যে কোনও উপায়ে আপনি সর্বদা ইন্টারফেস ব্যবহার করে পরোক্ষভাবে একাধিক উত্তরাধিকার প্রয়োগ করতে পারেন" " - যার জন্য বারবার এবং বার বার পদ্ধতির বডিটি পুনরায় নির্দিষ্ট করার জন্য প্রোগ্রামার প্রয়োজন।
কারি

13

কারণ জাভাতে সি ++ থেকে আলাদা আলাদা ডিজাইনের দর্শন রয়েছে। (আমি এখানে সি # নিয়ে আলোচনা করব না।)

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

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

আরও, জাভা অনেকাংশে সি ++ এবং স্মার্টটাক, সবচেয়ে পরিচিত ওও ভাষাগুলির একটি প্রতিক্রিয়া ছিল। অন্যান্য ওও ভাষা প্রচুর রয়েছে (এমআই আরও ভালভাবে পরিচালনা করে এমন বিভিন্ন ওও সিস্টেমের সাথে প্রচলিত লিস্প আসলে প্রথমটি প্রমিত করা হয়েছিল)।

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

এখানে কোন সঠিক উত্তর নেই। বিভিন্ন উত্তর রয়েছে এবং প্রদত্ত পরিস্থিতির জন্য কোনটি ভাল তা অ্যাপ্লিকেশন এবং স্বতন্ত্র পছন্দের উপর নির্ভর করে।


12

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


8

সি ++ তে একাধিক উত্তরাধিকার ছিল যখন একটি প্রধান মাথাব্যথা ছিল যখন ভুলভাবে ব্যবহার করা হত। এই জনপ্রিয় নকশার সমস্যাগুলি এড়ানোর জন্য একাধিক ইন্টারফেস "আধুনিকতা" পরিবর্তে আধুনিক ভাষায় (জাভা, সি #) বাধ্য করা হয়েছিল।


8

একাধিক উত্তরাধিকার হ'ল

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

সুতরাং, জাভা ভাষার মধ্যে একাধিক উত্তরাধিকার অন্তর্ভুক্ত না করা এটি একটি বুদ্ধিমান পছন্দ হিসাবে বিবেচনা করা যেতে পারে ।


3
কমন লিস্প অবজেক্ট সিস্টেমের সাথে কাজ করে আমি উপরের সমস্তগুলির সাথে একমত নই।
ডেভিড থর্নলে

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

5

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


4

পুরানো দিনগুলিতে ('70s) যখন কম্পিউটার বিজ্ঞান ছিল বেশি বিজ্ঞান এবং কম ভর উত্পাদন তখন প্রোগ্রামারদের ভাল নকশা এবং ভাল বাস্তবায়ন সম্পর্কে চিন্তা করার সময় ছিল এবং ফলস্বরূপ পণ্যগুলিতে (প্রোগ্রামগুলি) উচ্চ মানের ছিল (যেমন। টিসিপি / আইপি ডিজাইন) এবং বাস্তবায়ন)। আজকাল, যখন প্রত্যেকে প্রোগ্রামিং করছে, এবং পরিচালকগণ সময়সীমার আগে চশমা পরিবর্তন করছেন, স্টিভ হাই পোস্টের উইকিপিডিয়া লিঙ্কে বর্ণিত মত সূক্ষ্ম বিষয়গুলি ট্র্যাক করা কঠিন; সুতরাং, "একাধিক উত্তরাধিকার" সংকলক ডিজাইনের মাধ্যমে সীমাবদ্ধ। আপনি যদি এটি পছন্দ করেন তবে আপনি এখনও সি ++ ব্যবহার করতে পারেন .... এবং আপনার যে সমস্ত স্বাধীনতা চান তা পেতে পারেন :)


4
... নিজেকে একাধিকবার পায়ে গুলি করার স্বাধীনতা সহ;)
মারিও অর্টেগন

4

আমি এক চিমটি নুন দিয়ে "জাভাতে একাধিক উত্তরাধিকার অনুমোদিত নয়" এই বিবৃতিটি গ্রহণ করি।

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


6
তবে আপনি কোনও ইন্টারফেস থেকে উত্তরাধিকারী হন না, আপনি এটি বাস্তবায়ন করেন। ইন্টারফেসগুলি ক্লাস নয়।
ব্লারগবার্ড

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

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

4

শ্রেণীর গতিময় লোড একাধিক উত্তরাধিকারের বাস্তবায়নকে কঠিন করে তোলে।

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

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

সি ++ এ ভার্চুয়াল ফাংশনগুলি হ্যান্ডেল করতে ব্যবহৃত হয় এবং আমাদের স্পষ্টভাবে করতে হয়।

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


3

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


2

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

বা, সুপারক্লাস কনস্ট্রাক্টরকে কল করার সময় super()কোন সুপার ক্লাসের কনস্ট্রাক্টর ডাকবে ?

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


মৌলিকভাবে, জাভার টাইপ সিস্টেমটি ধরে নিয়েছে যে প্রতিটি বস্তুর উদাহরণের একটি প্রকার রয়েছে, একটি সুপারটাইপের কাছে কোনও বস্তু ingালাই সর্বদা কাজ করবে এবং রেফারেন্স-সংরক্ষণ করবে এবং সাব-টাইপের একটি রেফারেন্স castালাই রেফারেন্স-সংরক্ষণযোগ্য হবে যদি উদাহরণটি সেই সাব-টাইপের বা একটি এর সাব টাইপ। এই ধরনের অনুমানগুলি কার্যকর এবং আমি মনে করি না যে তাদের সাথে সামঞ্জস্যপূর্ণ একাধিক উত্তরাধিকারকে একত্রে অনুমতি দেওয়া সম্ভব।
সুপারক্যাট

1

সরাসরি জাভাতে একাধিক উত্তরাধিকার অনুমোদিত নয়, তবে ইন্টারফেসের মাধ্যমে এটি অনুমোদিত।

কারণ:

একাধিক উত্তরাধিকার: আরও জটিলতা এবং অস্পষ্টতার পরিচয় দেয়।

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

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

সহজ উদাহরণ নিতে দিন।

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

       public class A                               
         {
           void display()
             {
               System.out.println("Hello 'A' ");
             }
         }
    
       public class B                               
          {
            void display()
              {
                System.out.println("Hello 'B' ");
              }
          }
    
      public class C extends A, B    // which is not possible in java
        {
          public static void main(String args[])
            {
              C object = new C();
              object.display();  // Here there is confusion,which display() to call, method from A class or B class
            }
        }
  2. তবে ইন্টারফেসের মাধ্যমে (প্রয়োগকারী) কীওয়ার্ড সহ একাধিক উত্তরাধিকার সম্ভব।

    interface A
        {
           // display()
        }
    
    
     interface B
        {
          //display()
        }
    
     class C implements A,B
        {
           //main()
           C object = new C();
           (A)object.display();     // call A's display
    
           (B)object.display(); //call B's display
        }
    }

0

কেউ আমাকে সঠিকভাবে বলতে পারেন কেন এটি অনুমোদিত নয়?

আপনি এই ডকুমেন্টেশন লিঙ্ক থেকে উত্তর খুঁজে পেতে পারেন

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

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

  1. যদি বিভিন্ন সুপার ক্লাসের পদ্ধতি বা নির্মাণকারীরা একই ক্ষেত্রটি ইনস্ট্যান্ট করে?

  2. কোন পদ্ধতি বা নির্মাতা অগ্রাধিকার গ্রহণ করবে?

যদিও রাষ্ট্রের একাধিক উত্তরাধিকার অনুমোদিত, তবুও আপনি প্রয়োগ করতে পারেন

একাধিক প্রকারের উত্তরাধিকার : একাধিক ইন্টারফেস প্রয়োগের শ্রেণীর সক্ষমতা।

বাস্তবায়নের একাধিক উত্তরাধিকার (ইন্টারফেসে ডিফল্ট পদ্ধতির মাধ্যমে): একাধিক শ্রেণি থেকে পদ্ধতি সংজ্ঞা অর্জন করার ক্ষমতা

অতিরিক্ত তথ্যের জন্য এই সম্পর্কিত এসই প্রশ্নটি দেখুন:

ইন্টারফেসের সাথে একাধিক উত্তরাধিকারের দ্ব্যর্থতা


0

সি ++ তে একটি শ্রেণি একাধিক শ্রেণীর থেকে প্রত্যক্ষ (প্রত্যক্ষ বা পরোক্ষভাবে) উত্তরাধিকারী হতে পারে, যাকে একাধিক উত্তরাধিকার হিসাবে উল্লেখ করা হয়

সি # এবং জাভা যাইহোক, ক্লাসগুলি একক উত্তরাধিকারের মধ্যে ক্লাস সীমাবদ্ধ করে প্রতিটি শ্রেণি একক পিতা-মাতার ক্লাস থেকে উত্তরাধিকার সূত্রে আসে।

একাধিক উত্তরাধিকার হ'ল দুটি পৃথক শ্রেণীর শ্রেণিবিন্যাসের দিকগুলি একত্রিত করে এমন ক্লাস তৈরির একটি দরকারী উপায়, যা একক প্রয়োগের মধ্যে বিভিন্ন শ্রেণির কাঠামো ব্যবহার করার সময় প্রায়শই ঘটে।

যদি দুটি ফ্রেমওয়ার্কগুলি ব্যতিক্রমগুলির জন্য তাদের নিজস্ব বেস ক্লাসগুলি সংজ্ঞায়িত করে, উদাহরণস্বরূপ, আপনি ব্যতিক্রম কাঠামো তৈরি করতে একাধিক উত্তরাধিকার ব্যবহার করতে পারেন যা উভয় কাঠামোর সাথে ব্যবহার করা যেতে পারে।

একাধিক উত্তরাধিকারের সমস্যাটি এটি দ্ব্যর্থহীনতার দিকে নিয়ে যেতে পারে। ক্লাসিক উদাহরণটি যখন কোনও শ্রেণি অন্য দুটি শ্রেণির উত্তরাধিকার সূত্রে প্রাপ্ত হয়, যার প্রত্যেকটি একই বর্গ থেকে উত্তরাধিকার সূত্রে আসে:

class A {
    protected:
    bool flag;
};
class B : public A {};
class C : public A {};
class D : public B, public C {
    public:
    void setFlag( bool nflag ){
        flag = nflag; // ambiguous
    }
};

এই উদাহরণে, flagডেটা সদস্য দ্বারা সংজ্ঞায়িত করা হয় class A। কিন্তু class Dথেকে বর্ষিত হয় class B এবং class C, যা উভয় আহরণ থেকে A, ভব, যাতে দু কপি এর flagকারণ দুটি দৃষ্টান্ত পাওয়া যায় Aহয় Dএর বর্গ অনুক্রমের। আপনি কোনটি সেট করতে চান? কম্পাইলার অভিযোগ করবে রেফারেন্স flagমধ্যে Dহয় দ্ব্যর্থক । একটি সমাধান হ'ল সুস্পষ্টভাবে রেফারেন্সটি ছিন্ন করা:

B::flag = nflag;

আরেকটি সংশোধন হ'ল বি এবং সি হিসাবে ঘোষণা করা virtual base classes , যার অর্থ হ'ল শ্রেণীর মধ্যে কেবলমাত্র একটি অনুলিপি উপস্থিত থাকতে পারে, যে কোনও অস্পষ্টতা দূর করে।

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

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


-1

এই উদাহরণটি কল্পনা করুন: আমার একটি ক্লাস রয়েছে Shape1

এটির CalcualteAreaপদ্ধতি রয়েছে:

Class Shape1
{

 public void CalculateArea()

     {
       //
     }
}

অন্য শ্রেণি আছে Shape2যে একটি একই পদ্ধতি আছে

Class Shape2
{

 public void CalculateArea()

     {

     }
}

এখন আমার চাইল্ড ক্লাস সার্কেল রয়েছে, এটি শেপ 1 এবং শেপ 2 উভয় থেকেই এসেছে;

public class Circle: Shape1, Shape2
{
}

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

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


ভাষা ডিজাইনার ইন্টারফেসের মতো স্পষ্ট পদ্ধতিতে কল দিতে পারে। এরকম কোনও কথা নেই! আর একটি কারণ বিমূর্ত পদ্ধতি সহ বিমূর্ত শ্রেণি সম্পর্কে এখন আপনি এটি কীভাবে বিবেচনা করছেন?
নওমি আলী
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.