সি ++ এবং জাভাতে বিমূর্ত শ্রেণি / ইন্টারফেসের জন্য আলাদা ব্যবহারের যুক্তি রয়েছে কি?


13

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


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

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

1
সম্ভবত সম্পর্কিত: স্ট্যাকওভারফ্লো.com / q / 1231985 / 484230 জাভাতে অ্যাবস্ট্রাক্ট ক্লাস পছন্দ করতে একটি কারণ দেয়। সি ++ এর জন্য ইন্টারফেস স্তরে কার্যকারিতা যুক্ত করতে পারে এমন ফ্রি ফাংশনগুলির অস্তিত্বের কারণে এই কারণটি সত্য বলে মনে হচ্ছে না
মার্টিন

1
আমি মনে করি যে গোল্ডেন বিধিটি "নন-পাতাকে ক্লাসগুলি বিমূর্ত করা", তবে এটি কোনও "কেবল খাঁটি" বা "খালি" প্রয়োজনীয়তা তৈরি করে না।
কেরেক এসবি 21

1
যদি এটি আপনার পক্ষে কাজ করে তবে এটি আপনার পক্ষে কাজ করে। আমি সত্যিই দেখতে পাই না যে লোকেরা কেন একবার ঘাবড়ে যায় তাদের কোডটি সর্বশেষ মতামতের সাথে মেনে চলে না।
জেমস

উত্তর:


5

OOP রচনা এবং বিকল্প রয়েছে।

সি ++ এর একাধিক উত্তরাধিকার, টেম্পলেট বিশেষীকরণ, এম্বেডিং এবং মান / চাল / পয়েন্টার শব্দার্থক রয়েছে।

জাভা একক উত্তরাধিকার এবং ইন্টারফেস, এম্বেডিং এবং রেফারেন্স শব্দার্থবিজ্ঞান আছে।

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

জাভা তার নিজস্ব java.lang.Objectশিকড় হাইরাচি দিয়ে এই সব করে । সি ++ এর পূর্বনির্ধারিত প্রচলিত মূল নেই, সুতরাং একই "চিত্র" এ আসার জন্য আপনার কমপক্ষে এটি সংজ্ঞায়িত করা উচিত (তবে এটি কিছু সি ++ সম্ভাবনা সীমাবদ্ধ করছে ...)।

এরপরে, সংকলন-কাল পলিমারফিজম (সিআরটিপিকে ভাবুন) এবং মান সিমনেটের সম্ভাবনাটি অন্যান্য ওসিও যেমন "ওওপি অবজেক্ট" ধারণাকে সি ++ প্রোগ্রামে পোর্ট করা যায় তার বিকল্পও দিতে পারে।

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

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

ওওপি-এর সাথে জাভা সি সি ++ এর সাথে তুলনা করা কেবলমাত্র একটি এবং কেবল ওওপি উপায় উভয় ভাষার সক্ষমতা সীমাবদ্ধ করে দিচ্ছে।

জাভা কোডিং আইডিয়ামগুলিকে কঠোরভাবে মেনে চলতে সি ++ কে বাধ্য করা সি ++ কে জাভাটিকে সি ++ হিসাবে আচরণ করতে বাধ্য করা হিসাবে জোর করে - যেমন ভাষা জাভাটিকে অস্বীকার করছে।

"সংবেদনশীলতা" এর বিষয় নয় বরং দুটি "একত্রিতকরণ প্রক্রিয়া "গুলির জন্য দুটি ভাষার রয়েছে এবং তাদের একত্রিত করার বিভিন্ন উপায় যা কিছু ভাষায় প্রতিভাটিকে অন্য ভাষায় তুলনামূলকভাবে অন্য ভাষায় আরও লাভজনক করে তোলে।


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

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

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

12

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

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


সুতরাং আপনি সি ++ এ কোনও ইন্টারফেস ক্লাসের চেয়ে কোনও বিমূর্ত ক্লাসটি কখন পছন্দ করবেন? আমি সর্বদা সি ++ এ ইন্টারফেস প্লাস অ-সদস্য ফাংশন বেছে নিয়েছিলাম।
মার্টিন

1
@ মার্টিন যা ডিজাইনের উপর নির্ভর করে। মূলত, সর্বদা একটি ইন্টারফেস পছন্দ করুন। তবে " সর্বদা " নিয়মের ব্যতিক্রম রয়েছে ...
লুচিয়ান গ্রিগোর

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

3
@ মার্টিন ওয়েল ফ্রি ফাংশন জাভাতে মোটেই সম্ভব নয়, তাই এটি হ্যাঁ হতে পারে। ভাল জায়গা! আপনার নিজের প্রশ্নের উত্তর! আপনি নিজেই একটি উত্তর যুক্ত করতে পারেন, আমি মনে করি এটিই।
লুচিয়ান গ্রিগোর

4

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


0

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

virtual PrintError(string msg) { cout << msg; }

এটি যদি প্রয়োজন হয় তবে এটি ওভাররাইড করা যেতে পারে তবে ক্লায়েন্টকে কেবল জেনেরিক সংস্করণে কল করার অনুমতি দিয়ে কিছু ঝামেলা বাঁচাতে পারেন।

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