একাধিক উত্তরাধিকার ঘৃণা করার কোন "সত্য" কারণ আছে?

Question

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

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

এই সমস্যা সম্পর্কে সচেতন হওয়া যুদ্ধের 90%। তদুপরি আমি মনে করি যে আমি একটি সাধারণ-উদ্দেশ্যমূলক কাজের সম্পর্কে "খাম" এলগরিদম বা এমন কিছু জড়িত সম্পর্কে কিছু শুনেছিলাম (এটি কি কোনও ঘন্টা বাজায়, কেউ?)

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

যাতে সমস্ত বলা হচ্ছে ... এমন কোনও বাস্তব কারণ আছে যা বেশিরভাগ লোক একাধিক উত্তরাধিকারকে ঘৃণা করে, বা এগুলি কি হিস্টিরিয়ার একগুচ্ছ যা ভাল হওয়ার চেয়ে বেশি ক্ষতির কারণ? এমন কিছু আছে যা আমি এখানে দেখছি না? ধন্যবাদ.

উদাহরণ

কারটি হুইলডহেলকে প্রসারিত করে, কেআইএএসস্পেক্টর প্রসারিত গাড়ি এবং বৈদ্যুতিন, কেআইএসপেক্টরে রেডিও রয়েছে। KIASpectra কেন বৈদ্যুতিন ধারণ করে না?

1. কারণ এটা হল একটি বৈদ্যুতিন। উত্তরাধিকার বনাম রচনাটি সর্বদা একটি সম্পর্ক-বনাম একটি সম্পর্ক হওয়া উচিত।

2. কারণ এটা হল একটি বৈদ্যুতিন। সেখানে জিনিসপত্র এবং তারপরে তার, সার্কিট বোর্ড, সুইচ ইত্যাদি রয়েছে।

3. কারণ এটা হল একটি বৈদ্যুতিন। যদি শীতকালে আপনার ব্যাটারিটি মারা যায়, আপনি ঠিক তেমন সমস্যায় পড়েছেন যেন আপনার সমস্ত চাকা হঠাৎ হারিয়ে গেছে।

ইন্টারফেস ব্যবহার করবেন না কেন? উদাহরণস্বরূপ # 3 নিন। আমি এটি বারবার লিখতে চাই না এবং এটি করার জন্য আমি সত্যিই কিছু উদ্ভট প্রক্সি সহায়ক শ্রেণি তৈরি করতে চাই না:

private void runOrDont()
{
    if (this.battery)
    {
        if (this.battery.working && this.switchedOn)
        {
            this.run();
            return;
        }
    }
    this.dontRun();
}

(আমরা বাস্তবায়ন ভাল বা খারাপ কিনা তা আমরা intoুকতে পারছি না)) আপনি কল্পনা করতে পারেন যে কীভাবে বৈদ্যুতিনের সাথে এইরকম বেশ কয়েকটি ফাংশন থাকতে পারে যা হুইলেডভিহিকেলের কোনও কিছুর সাথে সম্পর্কিত নয় এবং তদ্বিপরীত।

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

Comments

এটি রচনার উপর উত্তরাধিকারকেও উত্সাহ দেয় ... (যখন এটি অন্যভাবে হওয়া উচিত)

— রাচেট ফ্রিক

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

— ফোশি

একাধিক ভাষায় একাধিক উত্তরাধিকার সুরক্ষিত বিকল্প রয়েছে, যা ইন্টারফেসের বাইরে beyond স্কালার পরীক্ষা করুন Traits- এগুলি optionচ্ছিক বাস্তবায়নের সাথে ইন্টারফেসের মতো কাজ করে তবে কিছু বিধিনিষেধ রয়েছে যা হীরা সমস্যা তৈরি হতে বাধা দিতে সহায়তা করে।

— কেচালাক্স

পূর্বে বন্ধ হওয়া এই প্রশ্নটিও দেখুন: প্রোগ্রামারস.স্ট্যাকেক্সেঞ্জার.কম

— ডক ব্রাউন

KiaSpectraনয় একটি Electronic ; এটিতে ইলেকট্রনিক্স রয়েছে এবং এটি হতে পারে ElectronicCar(যা প্রসারিত হবে Car...)

— ব্রায়ান এস

Answer 1

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

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

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

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

একটি আয়তক্ষেত্র থেকে উত্তরাধিকার সূত্রে প্রাপ্ত বর্গের ক্লাসিক উদাহরণ নিন। আয়তক্ষেত্রটি দৈর্ঘ্য এবং প্রস্থের সম্পত্তি এবং একটি getPerimeter এবং getArea পদ্ধতি প্রকাশ করে। বর্গক্ষেত্র দৈর্ঘ্য এবং প্রস্থকে ওভাররাইড করবে যাতে একটি সেট করা হয়ে গেলে অপরটি getPerimeter এর সাথে মিলিত হয় এবং getArea একই কাজ করবে (2 * দৈর্ঘ্য + 2 * প্রস্থের জন্য দৈর্ঘ্য এবং ক্ষেত্রের জন্য দৈর্ঘ্য * প্রস্থ)।

একটি একক পরীক্ষার কেস রয়েছে যা আপনি যদি আয়তক্ষেত্রের জন্য বর্গক্ষেত্রের এই বাস্তবায়নটিকে বিকল্প হিসাবে প্রতিহত করেন break

var rectangle = new Square();
rectangle.length= 5;
rectangle.width= 6;
Assert.AreEqual(30, rectangle.GetArea()); 
//Square returns 36 because setting the width clobbers the length

একক উত্তরাধিকার শৃঙ্খলে জিনিসগুলি সঠিকভাবে পাওয়া যথেষ্ট শক্ত। আপনি আরও একটি মিশ্রণ যুক্ত করলে এটি আরও খারাপ হয়।

---

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

এবং আমি সম্মত হই যে এমআইকে কেন ভ্রান্ত করা হচ্ছে তার একটি "বাস্তব জগত" উদাহরণ দিয়ে আমি কিছুটা প্রতারণা করেছি।

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

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

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

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

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

আশা করা যায় যে এটি কেন একাধিক উত্তরাধিকারকে সাধারণত নিম্নমানের করা হয় সে সম্পর্কে আরও কিছুটা অন্তর্দৃষ্টি প্রদান করে।

Comments

"ম্যান আমার সঠিকভাবে এটি করার জন্য এমআই প্রয়োজন" - একজন উত্তম ব্যক্তির জন্য আমার উত্তর দেখুন। সংক্ষেপে, অরথোগোনাল ধারণাগুলি যে কোনও সম্পর্ককে সন্তুষ্ট করে তা এমআইয়ের পক্ষে বোঝা যায়। এগুলি খুব বিরল, তবে তারা বিদ্যমান।

— মিঃফক্স

মানুষ, আমি বর্গাকার আয়তক্ষেত্রের উদাহরণটিকে ঘৃণা করি। আরও প্রচুর আলোকিত উদাহরণ রয়েছে যেগুলির পরিবর্তনের প্রয়োজন হয় না।

— asmeurer

আমি ভালবাসি যে "একটি বাস্তব উদাহরণ সরবরাহ" এর উত্তর ছিল একটি কাল্পনিক প্রাণী নিয়ে আলোচনা করা। দুর্দান্ত

— বিড়ম্বনা

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

— ctrl-alt-delor

আমি মনে করি না যে এই উদাহরণগুলি সত্যই কার্যকর হয় ... কেউ বলে না যে পেগাসাস একটি পাখি এবং একটি ঘোড়া ... আপনি বলেছেন এটি উইংসডএনিমাল এবং একটি হুফেডঅনিমাল। বর্গক্ষেত্র এবং আয়তক্ষেত্রের উদাহরণটি আরও কিছুটা অর্থবোধ করে কারণ আপনি নিজেকে এমন একটি বস্তুর সাথে খুঁজে পান যা তার দৃserted় সংজ্ঞাটির উপর ভিত্তি করে ভাবতে চেয়ে আলাদাভাবে আচরণ করে। তবে আমি মনে করি যে এই পরিস্থিতিটি এটি না ধরার জন্য প্রোগ্রামারদের দোষ হবে (যদি সত্যই এটি কোনও সমস্যা প্রমাণিত হয়) did

— রিচার্ড

Answer 2

এমন কিছু আছে যা আমি এখানে দেখছি না?

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

আরেকটি সাধারণ যুক্তি যা আমি দেখেছি (এবং সময়ে তৈরি হয়েছিল তা হ'ল দুটি + বেস ক্লাস করার ফলে আপনার অবজেক্টটি প্রায় অবিচ্ছিন্নভাবে একক দায়িত্বের নীতি লঙ্ঘন করে। হয় দুটি + বেস ক্লাসগুলি তাদের নিজস্ব দায়বদ্ধতার (লঙ্ঘনের কারণ) সহ দুর্দান্ত স্ব-সংযুক্ত ক্লাস বা তারা আংশিক / বিমূর্ত প্রকার যা একে অপরের সাথে একক সমন্বিত দায়িত্ব পালনে কাজ করে।

এই অন্যান্য ক্ষেত্রে, আপনার কাছে 3 টি দৃশ্য রয়েছে:

1. এ বি সম্পর্কে কিছুই জানে না - গ্রেট, আপনি ভাগ্যবান হওয়ার কারণে আপনি ক্লাসগুলি একত্রিত করতে পারেন।
2. এ বি সম্পর্কে জানে - কেন কেবল খ থেকে উত্তরাধিকার সূত্রে প্রাপ্ত হয়নি?
3. এ এবং বি একে অপরের সম্পর্কে জানে - আপনি কেবল একটি ক্লাস করেননি কেন? এই জিনিসগুলিকে এত বেশি সংযুক্ত করে আংশিকভাবে পুনঃস্থাপনযোগ্য করে কী লাভ?

ব্যক্তিগতভাবে, আমি মনে করি একাধিক উত্তরাধিকারের খারাপ র‌্যাপ রয়েছে, এবং বৈশিষ্ট্যযুক্ত স্টাইলের রচনাটির একটি ভালভাবে সম্পন্ন পদ্ধতিটি সত্যই শক্তিশালী / দরকারী হবে ... তবে এর অনেকগুলি উপায় রয়েছে যা এটি খারাপভাবে প্রয়োগ করা যেতে পারে, এবং এর অনেকগুলি কারণ রয়েছে সি ++ এর মতো ভাষায় ভাল ধারণা নয়।

[সম্পাদনা] আপনার উদাহরণ সম্পর্কিত, এটি অযৌক্তিক। একজন কিয়া হয়েছে ইলেক্ট্রনিক্স। এটা তোলে হয়েছে একটি ইঞ্জিন। অনুরূপভাবে, এটা ইলেকট্রনিক্স এর আছে একটি শক্তি উৎস, যা শুধু একটি গাড়ির ব্যাটারি হতে হবে। উত্তরাধিকার, একা একা একাধিক উত্তরাধিকারের কোনও স্থান নেই।

Comments

আর একটি আকর্ষণীয় প্রশ্ন হল বেস ক্লাসগুলি কীভাবে তাদের বেস ক্লাসগুলি আরম্ভ করা হয়। এনক্যাপসুলেশন> উত্তরাধিকার।

— জোজেফগ

"বৈশিষ্ট্য শৈলী রচনার ভাল কাজ করেছেন সিস্টেম সত্যিই শক্তিশালী / দরকারী হবে ..." - এই নামে পরিচিত হয় mixins , এবং তারা হয় ক্ষমতাশালী / দরকারী। মিক্সিনগুলি এমআই ব্যবহার করে প্রয়োগ করা যেতে পারে, তবে মিক্সিনগুলির জন্য একাধিক উত্তরাধিকারের প্রয়োজন নেই। কিছু ভাষাগুলি এমআই ছাড়াই সহজাতভাবে মিশ্রণগুলিকে সমর্থন করে।

— ব্লুরাজা - ড্যানি পিফ্লুঘুফুট

বিশেষত জাভার জন্য, আমাদের ইতিমধ্যে একাধিক ইন্টারফেস এবং INVOKEINTERFACE রয়েছে, সুতরাং এমআই এর কোনও সুস্পষ্ট কর্মক্ষমতা প্রভাব ফেলবে না।

— ড্যানিয়েল লুবারভ

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

— রিচার্ড

Answer 3

এটি নিষিদ্ধ হওয়ার একমাত্র কারণ হ'ল এটি পায়ে নিজেকে গুলি করা সহজ করে।

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

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

তবে না, এমন একদম দৃ conv়প্রত্যয়ী সত্য যুক্তি উপস্থিত নেই যা একাধিক উত্তরাধিকারকে একটি খারাপ ধারণা হিসাবে প্রমাণ করে।

সম্পাদনা

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

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

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

এই সমস্যার আসল সমাধান হ'ল আপনার ডেটা মডেল তৈরি করতে একাধিক উত্তরাধিকার ব্যবহার করে ইক্যুইটি, tণ, ডেরিভেটিভ, সূচক প্রকারগুলি সংজ্ঞায়িত এবং মিশ্রিত করা। এটি এমন বস্তু তৈরি করবে যা উভয়ই বুদ্ধিমান এবং কোডটি পুনরায় ব্যবহারের জন্য সহজে leণ দেয় le

Comments

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

— মাইকেল ব্রাউন

এটি আমার কাছে ইন্টারফেসগুলির সাথে খুব দ্রবণযোগ্য বলে মনে হচ্ছে ... আসলে এটি অন্য যে কোনও কিছুর চেয়ে ইন্টারফেসের পক্ষে ভাল seems Equityএবং Debtউভয় বাস্তবায়ন ISecurity। Derivativeএকটি ISecurityসম্পত্তি আছে। এটি নিজেই ISecurityযদি উপযুক্ত হয় তবে (আমি ফিন্যান্স জানি না)। IndexedSecuritiesআবার একটি ইন্টারফেস সম্পত্তি রয়েছে যা এটির ভিত্তিতে অনুমোদিত হওয়ার ধরণের ক্ষেত্রে প্রয়োগ হয়। যদি তারা সবাই থাকে ISecurityতবে তাদের সবার ISecurityসম্পত্তি আছে এবং নির্বিচারে

— বাসা বাঁধতে

@ بابসোন সমস্যাটি এসেছে যে আপনাকে প্রতিটি প্রয়োগকারীর জন্য ইন্টারফেসটি পুনরায় প্রয়োগ করতে হবে এবং অনেক ক্ষেত্রে এটি ঠিক একই। আপনি প্রতিনিধি / রচনা ব্যবহার করতে পারেন তবে তারপরে আপনি ব্যক্তিগত সদস্যদের অ্যাক্সেস হারাবেন। এবং যেহেতু জাভাতে প্রতিনিধি / ল্যাম্বডাস নেই ... আক্ষরিকভাবে এটি করার কোনও ভাল উপায় নেই। Aspect4J

— মাইকেল ব্রাউন

মাইক্র ব্রাউন যা বলেছেন ঠিক তেমনই বোবিসন। হ্যাঁ, আপনি ইন্টারফেসগুলির সাহায্যে একটি সমাধান ডিজাইন করতে পারেন তবে এটি আটকানো হবে। ইন্টারফেস ব্যবহার করার জন্য আপনার স্বজ্ঞাততা যদিও খুব সঠিক, এটি মিক্সিন / একাধিক উত্তরাধিকার :) এর জন্য একটি লুকানো ইচ্ছা।

— মিঃফক্স

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

— শন উইলসন

Answer 4

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

class Foo(object):
   def zeta(self):
      print "foozeta"

class Bar(object):
   def zeta(self):
      print "barzeta"

   def barstuff(self):
      print "barstuff"
      self.zeta()

class Bang(Foo, Bar):
   def stuff(self):
      self.zeta()
      print "---"
      self.barstuff()

z = Bang()
z.stuff()

Barএটির নিজস্ব বাস্তবায়ন রয়েছে বলে ধরে নেওয়া হয়েছিল zeta(), যা সাধারণত একটি দুর্দান্ত ধারণা um একটি সাবক্লাস এটিকে যথাযথভাবে ওভাররাইড করা উচিত যাতে এটি সঠিক কাজ করে। দুর্ভাগ্যক্রমে, নামগুলি কেবল কাকতালীয়ভাবে একই ছিল - তারা ভিন্ন ভিন্ন কাজ করেছে, কিন্তু Barএখন এটি Fooবাস্তবায়নের ডাক দিচ্ছে :

foozeta
---
barstuff
foozeta

এটির পরিবর্তে হতাশাব্যঞ্জক হয় যখন কোনও ত্রুটি নিক্ষেপ করা হয় না, অ্যাপ্লিকেশনটি ঠিক তখন থেকে কিছুটা ভুল কাজ শুরু করে এবং কোড পরিবর্তনের কারণে এটি তৈরি হয়েছে (সৃষ্টি করা Bar.zeta) সমস্যাটি মনে হচ্ছে না বলে মনে হয়।

Comments

কল করার মাধ্যমে ডায়মন্ড সমস্যা কীভাবে এড়ানো যায় super()?

— Panzercrisis

@ পানজারক্রিসিস দুঃখিত, এই অংশটুকু মনে রাখবেন না। আমি "হীরা সমস্যা" বলতে সাধারণত কোন সমস্যাটি উল্লেখ করেছি - পাইথনের কাছে হীরা-আকৃতির উত্তরাধিকারের কারণে পৃথক পৃথক সমস্যা super()হয়েছিল

— ইজকাটা

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

— থমাস এডিং

বংশগতিবিদ্যার অনুক্রম পরিবর্তন Bangকরার Bar, Fooএছাড়াও সমস্যাটি সমাধানের হবে - কিন্তু আপনার একটি ভাল এক +1 হয়।

— শান ভিইরা

আপনি @ThomasEding নিজে এখনো দুর্বোধ্য পারেন: Bar.zeta(self)।

— টাইলার ক্রম্পটন

Answer 5

আমি যুক্তি দিয়ে বলব যে এমআইয়ের সাথে সঠিক ভাষায় কোনও আসল সমস্যা নেই । মূল হ'ল স্ট্রাকচারকে মঞ্জুরি দেওয়ার জন্য, তবে কোনও নিয়মের উপর ভিত্তি করে বাস্তবায়নগুলির মধ্যে সংকলকটিকে বাছাইয়ের পরিবর্তে সাব টাইপগুলি তাদের নিজস্ব ওভাররাইড সরবরাহ করে।

আমি এটি গুয়ারাতে করি , আমি যে ভাষাতে কাজ করছি working পেয়ারার একটি বৈশিষ্ট্য হ'ল আমরা কোনও পদ্ধতির নির্দিষ্ট সুপারটাইপের প্রয়োগ করতে পারি। সুতরাং কোন বিশেষ বিন্যাস ছাড়াই কোন সুপারটাইপ বাস্তবায়ন "উত্তরাধিকার সূত্রে প্রাপ্ত হওয়া উচিত" তা বোঝানো সহজ:

type Sequence[+A] {
  String toString() {
    return "[" + ... + "]";
  }
}

type Set[+A] {
  String toString() {
    return "{" + ... + "}";
  }
}

type OrderedSet[+A] extends Sequence[A], Set[A] {
  String toString() {
    // This is Guava's syntax for statically invoking instance methods
    return Set.toString(this);
  }
}

আমরা যদি OrderedSetএটির নিজস্ব না দিয়ে toStringথাকি তবে আমরা একটি সংকলন ত্রুটি পেয়ে যাব। কোন চমক নাই.

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

type Enumerable[+A] {
  Source[A] getEnumerator();
}

type Sequence[+A] extends Enumerable[A] {
  A get(Int index);
}

type RandomlyEnumerableSequence[+A] extends Sequence[A] {
  Source[A] getEnumerator() {
    ...
  }
}

type DynamicArray[A] extends MutableStack[A],
                             RandomlyEnumerableSequence[A] {
  // No need to define getEnumerator.
}

যদি আমাদের এমআই না থাকে তবে আমরা RandomAccessEnumeratorবেশ কয়েকটি সংগ্রহের জন্য একটি লিখতে পারতাম , তবে একটি সংক্ষিপ্ত getEnumeratorপদ্ধতি লিখতে এখনও বয়লারপ্লেট যুক্ত হয়।

একইভাবে, এমআই মান বাস্তবায়নের inheriting জন্য দরকারী equals, hashCodeএবং toStringসংগ্রহের জন্য।

Comments

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

— ড্যানিয়েল লুবারভ

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

— ড্যানিয়েল লুবারভ

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

— লামেজেডন

কেন তুমি কল Ordered extends Set and Sequenceএকটি Diamond? এটি একটি যোগদান মাত্র। hatএটিতে ভার্টেক্সের অভাব রয়েছে । আপনি এটিকে হীরা বলছেন কেন? আমি এখানে জিজ্ঞাসা করেছি তবে এটি একটি নিষিদ্ধ প্রশ্ন বলে মনে হচ্ছে। আপনি কীভাবে জানলেন যে এই ত্রিভুঙ্গাল কাঠামোটিকে যোগদানের পরিবর্তে ডায়মন্ড বলা দরকার?

— Val,

@ সনাক্ত করুন এভিলাসওয়াস্ট করুন যে ভাষার একটি অন্তর্নিহিত Topপ্রকার রয়েছে যা ঘোষণা করে toString, তাই আসলে হীরার কাঠামো ছিল। তবে আমি মনে করি আপনার একটি বক্তব্য আছে - হীরার কাঠামো ব্যতীত "যোগদান" একই ধরণের সমস্যা তৈরি করে এবং বেশিরভাগ ভাষা উভয় ক্ষেত্রে একইভাবে পরিচালনা করে।

— ড্যানিয়েল লুবারভ

Answer 6

উত্তরাধিকার, একাধিক বা অন্যথায়, এটি গুরুত্বপূর্ণ নয়। যদি বিভিন্ন ধরণের দুটি বস্তু পরিবর্তনযোগ্য হয় তবে তা উত্তরাধিকার দ্বারা সংযুক্ত না হলেও, এটি গুরুত্বপূর্ণ।

একটি লিঙ্কযুক্ত তালিকা এবং একটি চরিত্রের স্ট্রিং সামান্য মিল থাকে এবং উত্তরাধিকারসূত্রে লিঙ্ক করার প্রয়োজন হয় না তবে এটি কার্যকর যদি আমি lengthকোনও একটিতে উপাদানের সংখ্যা পেতে কোনও ফাংশন ব্যবহার করতে পারি।

কোডের বারবার প্রয়োগ এড়াতে উত্তরাধিকার একটি কৌশল। যদি উত্তরাধিকার আপনার কাজকে বাঁচায় এবং একক উত্তরাধিকারের তুলনায় একাধিক উত্তরাধিকার আপনাকে আরও বেশি কাজ বাঁচায়, তবে এটাই সমস্ত যুক্তিসঙ্গত প্রয়োজন।

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

অনেক ভাষায়, শ্রেণীর উত্তরাধিকার চিহ্নগুলির উত্তরাধিকারের সাথে আবদ্ধ হয়। আপনি যখন ক্লাস বি থেকে ক্লাস ডি সংগ্রহ করেন, কেবল আপনিই একটি প্রকারের সম্পর্ক তৈরি করছেন না, কারণ এই শ্রেণিগুলি লেজিকাল নেমস্পেস হিসাবেও কাজ করে, আপনি বি নামস্থান থেকে ডি নেমস্পেসে প্রতীকগুলি আমদানির বিষয়টিও পরিচালনা করছেন to বি এবং ডি টাইপগুলি নিয়ে কী ঘটছে এর শব্দার্থক। একাধিক উত্তরাধিকার প্রতীক সংঘাতের বিষয় নিয়ে আসে। যদি আমরা উত্তরাধিকারসূত্রে পাই card_deckএবং graphicউভয়ই একটি drawপদ্ধতি " থাকি " , drawতবে ফলাফলযুক্ত বস্তুর অর্থ কী ? যে কোনও অবজেক্ট সিস্টেমটিতে এই সমস্যা নেই তা হ'ল কমন লিস্পে। সম্ভবত কাকতালীয়ভাবে নয়, লিসপ প্রোগ্রামগুলিতে একাধিক উত্তরাধিকার ব্যবহৃত হয়।

খারাপভাবে প্রয়োগ করা হয়েছে, অসুবিধাগুলি কিছু (যেমন একাধিক উত্তরাধিকার) ঘৃণা করা উচিত ।

Comments

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

— BЈовић

@ বিЈовић এই দুজন একেবারেই "সম্পূর্ণ" আলাদা জিনিস করছে না।

— কাজ

Comparting স্ট্রিং এবং তালিকা , এক পুনরাবৃত্তি প্রচুর দেখতে পারেন। এই সাধারণ পদ্ধতি বাস্তবায়নের জন্য উত্তরাধিকার ব্যবহার করা সহজভাবে ভুল হবে।

— BЈовић

@ বিঃ উত্তরে উত্তরে বলা হয়নি যে স্ট্রিং এবং তালিকা উত্তরাধিকারসূত্রে লিঙ্ক করা উচিত; পুরোপুরি বিপরীত. কোনও lengthক্রিয়াকলাপে একটি তালিকা বা স্ট্রিং প্রতিস্থাপন করতে সক্ষম হওয়ার আচরণ উত্তরাধিকারের ধারণাটি থেকে স্বাধীনভাবে কার্যকর হয় (যা এই ক্ষেত্রে সহায়তা করে না: আমরা বাস্তবায়ন ভাগ করে নেওয়ার চেষ্টা করে কিছু অর্জন করতে সক্ষম হতে পারি না) lengthফাংশন দুটি পদ্ধতি )। তবুও কিছু বিমূর্ত উত্তরাধিকার থাকতে পারে: উদাহরণস্বরূপ তালিকা এবং স্ট্রিং উভয়ই টাইপ সিকোয়েন্স (তবে এটি কোনও বাস্তবায়ন সরবরাহ করে না)।

— কাজ

এছাড়াও, উত্তরাধিকার হ'ল একটি সাধারণ শ্রেণীর অংশগুলি রিফ্যাক্টর করার একটি উপায়: যথা বেস শ্রেণি।

— কাজ

Answer 7

যতদূর আমি বলতে পারি, সমস্যার একটি অংশ (আপনার নকশাটি বোঝার জন্য কিছুটা শক্ত করে তোলা (তবুও কোড করা সহজ)) হ'ল সংকলকটি আপনার শ্রেণীর ডেটার জন্য পর্যাপ্ত স্থান বাঁচাতে চলেছে, যার ফলে এটি বিশাল পরিমাণে নিম্নলিখিত ক্ষেত্রে স্মৃতি বর্জ্য:

(আমার উদাহরণটি সেরা নাও হতে পারে তবে একই উদ্দেশ্যে একাধিক স্মৃতি স্পেস সম্পর্কে সংক্ষেপে জানার চেষ্টা করুন, এটি আমার মনে প্রথম ছিল: পি)

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

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

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

Comments

কোন পয়েন্টে কোনও সংকলক কখনই ধরে নিতে পারে যে বিভিন্ন পিতা-মাতার ক্লাস থেকে একই নামের ভেরিয়েবলগুলি একত্রিত করা নিরাপদ? আপনার কী গ্যারান্টি রয়েছে যে caninus.diet এবং pet.diet আসলে একই উদ্দেশ্যে কাজ করে? একই নামে ফাংশন / পদ্ধতিগুলি দিয়ে আপনি কী করবেন?

— মিঃমিন্দর

হাহাহা আমি আপনার সাথে মিঃ মিঃ মাইন্ডর এর সাথে সম্পূর্ণরূপে একমত, আমি আমার উত্তরে যা বলছি ঠিক তা-ই আমার কাছে এলোমেলো কাছাকাছি আসার একমাত্র উপায় হ'ল প্রোটোটাইপ ভিত্তিক প্রোগ্রামিং, তবে আমি বলছি না এটি অসম্ভব , এবং যে ঠিক কারণ কেন আমি বললাম যে অনেক asumptions সংকলন সময়ে তৈরি করা আবশ্যক, এবং কিছু অতিরিক্ত "তথ্য" / especifications Teh প্রোগ্রামারের লেখা যেতে হবে (তা সত্ত্বেও এটি আরো কোডিং, যা মূল সমস্যা হয়েছে থাকে)

— Ordiel

Answer 8

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

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

কল্পনা করুন যে আপনি সবেমাত্র আপনার স্বপ্নের সংস্থা দ্বারা ভাড়া পেয়েছিলেন এবং তারপরে এই জাতীয় কোড বেস উত্তরাধিকার সূত্রে প্রাপ্ত। তদুপরি কল্পনা করুন যে পরামর্শকরা উত্তরাধিকার এবং একাধিক-উত্তরাধিকার সম্পর্কে শিখছিলেন (আপনি কীভাবে কাজ করছেন তা চিত্রিত করতে পারেন?

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

আপনার কোডের প্রতিটি আন্তঃসংযোগও একাধিক উত্তরাধিকারের সাথে দ্বিগুণভাবে স্বতন্ত্রভাবে টুকরোগুলি বুঝতে এবং সংশোধন করা আরও কঠিন করে তোলে।

আপনি যখন কোনও দলের অংশ হিসাবে কাজ করছেন আপনি সহজতম কোডটিকে টার্গেট করতে চান যা আপনাকে একেবারে কোনও বাজে রিলিজ্যান্ট যুক্তি দেয় না (ডিআরওয়াই সত্যিই এর অর্থ এটি নয় যে আপনাকে 2 তে নিজের কোড পরিবর্তন করতে হবে না এমনটি আপনাকে বেশি টাইপ করা উচিত নয়) সমস্যা সমাধানের জায়গা!)

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

Comments

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

— gbjbaanb

@gbjbaanb আপনি ঠিকই বলেছেন, যে কারওর জন্যই জ্বলন্ত জ্বালাপোড়া করা হয়নি তার পক্ষে সহজ - বাস্তবে এটি কীভাবে সর্বোত্তমভাবে ব্যবহার করা যায় তা দেখার জন্য এটি এমন কোনও বৈশিষ্ট্য শেখার জন্য এটি প্রায় প্রয়োজন it আমি এক ধরনের কৌতূহলী কারণ আপনি বলে যাচ্ছেন বলে মনে হচ্ছে যে এমআইকে আরও ডিআই / আইওসি করার দরকার নেই যা আমি দেখিনি - আমি মনে করব না যে পরামর্শক কোডটি আপনি সমস্ত কৃপণ ইন্টারফেস / ডিআই এর সাথে পেয়েছেন অনেকগুলি থেকে বহু উত্তরাধিকারী গাছের চেয়ে সম্পূর্ণ পাগল থাকা ভাল, তবে এটি এমআই এর সাথে আমার অনভিজ্ঞ হতে পারে। এমআই দিয়ে ডিআই / আইওসি প্রতিস্থাপনের বিষয়ে আমি কী পড়তে পারি?

— বিল কে

Answer 9

একাধিক উত্তরাধিকারের বিপরীতে বৃহত্তম যুক্তিটি হ'ল কিছু কার্যকর দক্ষতা সরবরাহ করা যেতে পারে এবং কিছু দরকারী অক্ষরেখা এমন কাঠামোয় ধারণ করতে পারে যা এটি (*) মারাত্মকভাবে সীমাবদ্ধ করে তবে সরবরাহ করা যায় না এবং / বা এ জাতীয় বিধিনিষেধ ব্যতীত রাখা যায় না। তাদের মধ্যে:

• একাধিক পৃথকভাবে সংকলিত মডিউলগুলির দক্ষতার মধ্যে অন্যান্য মডিউলের ক্লাস থেকে উত্তরাধিকারী ক্লাসগুলি অন্তর্ভুক্ত থাকে এবং সেই বেস ক্লাস থেকে উত্তরাধিকারসূত্রে প্রাপ্ত প্রতিটি মডিউল পুনরায় সংকলন না করে বেস ক্লাসযুক্ত একটি মডিউল পুনরায় সংকলন করে।

• কোনও প্রকারের জন্য পিতামাত্ত শ্রেণীর কাছ থেকে সদস্য প্রয়োগের উত্তরাধিকার সূত্রে প্রাপ্ত হওয়ার ক্ষমতাটি এটির পুনরায় প্রয়োগ করতে হবে type

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

• মূলসূত্রটি যে কোনও উত্পন্ন শ্রেণি যদি একটি বেস-শ্রেণীর সদস্যকে ওভাররাইড করে এবং চেইন করে, তবে বেস সদস্যকে শৃঙ্খলাবদ্ধ কোডের মাধ্যমে সরাসরি ডাকা হবে এবং অন্য কোথাও ডাকা হবে না।

(*) সাধারণত একাধিক উত্তরাধিকারকে সমর্থনকারী প্রকারগুলি ক্লাসের পরিবর্তে "ইন্টারফেস" হিসাবে ঘোষণা করা এবং সাধারণ শ্রেণিগুলি করতে পারে এমন সমস্ত কিছু করার জন্য ইন্টারফেসগুলিকে অনুমতি না দেওয়ার মাধ্যমে প্রয়োজনীয়তা অর্জন করে।

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

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

Comments

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

— সুপারক্যাট

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

— সিএইচও

@ সিএইচও: যদি কোনওরূপে প্রয়োজন হয় যে উত্সযুক্ত শ্রেণিগুলির অবশ্যই পিতামাতার পদ্ধতিগুলি ওভাররাইড করা উচিত এবং সেগুলি (ইন্টারফেসের মতো একই নিয়ম) দ্বারা চেইন না করা উচিত কেউ সমস্যা এড়াতে পারে, তবে এটি বেশ মারাত্মক সীমাবদ্ধতা। এক একটি প্যাটার্ন যেখানে ব্যবহার করে FirstDerivedFoo'এর গুলি ওভাররাইড Barএকটি সুরক্ষিত অ ভার্চুয়াল কিন্তু চেন কিছুই না FirstDerivedFoo_Bar, আর SecondDerivedFooকরার' র ওভাররাইড চেইন সংরক্ষিত অ ভার্চুয়াল SecondDerivedBar, এবং কোড বেস পদ্ধতি অ্যাক্সেস করতে চায় সেই সংরক্ষিত অ ভার্চুয়াল পদ্ধতি ব্যবহার করে, যে হতে পারে একটি কার্যক্ষম পদ্ধতির ...

— সুপারক্যাট 26'15

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

— সুপারক্যাট 26'15

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

— সিএইচও