একাধিক উত্তরাধিকার ব্যবহারের কেস


15

জাভা একাধিক উত্তরাধিকার বাদ দেয় যে কারণে এটি ভাষা সহজ রাখার নকশা লক্ষ্যকে মেনে চলে ।

আমি ভাবছি জাভা (এর ইকো-সিস্টেম সহ) সত্যই "সরল" কিনা। পাইথন জটিল নয় এবং একাধিক উত্তরাধিকার রয়েছে। সুতরাং খুব সাবজেক্টিভ না হয়ে আমার প্রশ্ন ...

একাধিক উত্তরাধিকার ভারী ব্যবহারের জন্য ডিজাইন করা কোড থেকে এমন সাধারণ সমস্যাগুলির ধরণগুলি কী কী?


8
জাভা খুব অল্প কারণে খুব ভয়ঙ্কর পুরোপুরি ভাল জিনিস বাদ দেয়। আমি এমআইয়ের জন্য একটি উপযুক্ত ন্যায়সঙ্গততা আশা করবো না।
ডেড এমজি

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

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

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

উত্তর:


11

পেশাদাররা:

  1. এটি কখনও কখনও সমস্যার অন্যান্য মডেলের মডেল তুলনায় আরও স্পষ্ট মডেলিংকে অনুমতি দেয়।
  2. যদি বিভিন্ন পারেন্টেন্টের অরথোগোনাল উদ্দেশ্য থাকে তবে এটি একরকম সংমিশ্রনের অনুমতি দিতে পারে

কনস:

  1. যদি বিভিন্ন পিতামাতার অরথোগোনাল উদ্দেশ্য না থাকে তবে এটি টাইপটি বোঝা কঠিন করে তোলে।
  2. এটি কোনও ভাষায় (যে কোনও ভাষায়) কীভাবে প্রয়োগ করা হয় তা বোঝা সহজ নয়।

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

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

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

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

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


আমি যদি আপনার উত্তরটিকে উদাহরণস্বরূপ সমস্যার সাথে অলংকৃত করি তবে আমি সত্যিই প্রশংসা করব - যা "
অরথগোনাল

ঠিক আছে আমাকে কিছু যুক্ত করার চেষ্টা করুন।
ক্লাইম

ডিজাইন অনুপ্রেরণার জন্য আমি ওগ্র্রে 3 ডি খুঁজছি এমন কোনও জায়গা নয়- আপনি কি তাদের সিঙ্গলটন সংক্রমণ দেখেছেন?
ডেড এমএমজি

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

4

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


+1 হ'ল একাধিক উত্তরাধিকার পাওয়ার জন্য এটি ভাল কারণ। মিকিনস অতিরিক্ত অর্থ বহন করে ("এই শ্রেণিটি একা হিসাবে ব্যবহার করা উচিত নয়")
ashes999

2

আমি মনে করি পছন্দটি হীরা সমস্যার কারণে মূলত ইস্যুগুলির উপর ভিত্তি করে ।

তদুপরি, প্রতিনিধি বা অন্য উপায়ে একাধিক উত্তরাধিকারের ব্যবহারকে অবহেলা করা সম্ভব।

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


2

আমি এখানে খুব বেশি কিছু দেবো না তবে আপনি নীচের লিঙ্কটি http://docs.python.org/release/1.5.1p1/tut/m Multiple.html এর মাধ্যমে পাইথনটির একাধিক উত্তরাধিকার অবশ্যই বুঝতে পারবেন :

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

...

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

এটি কেবলমাত্র একটি ছোট অনুচ্ছেদে তবে আমার অনুমানের সন্দেহগুলি সাফ করার পক্ষে এটি যথেষ্ট বড়।


1

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


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

1

একাধিক উত্তরাধিকার ভারী ব্যবহারের জন্য ডিজাইন করা কোড থেকে এমন সাধারণ সমস্যাগুলির ধরণগুলি কী কী?

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

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

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

সাধারণ উদাহরণ (কেউ কেউ পরীক্ষা করতে পারে যে কোনও ফাইল হ্যান্ডেল পাস হয়েছে তা খোলা আছে বা এরকম কিছু):

// Non-virtual interface (public methods are nonvirtual/final).
// Since these are modeling the concept of "interface", not ABC,
// multiple will often be inherited ("implemented") by a subclass.
class SomeInterface
{
public:
    // Pre: x should always be greater than or equal to zero.
    void f(int x) /*final*/
    {
        // Make sure x is actually greater than or equal to zero
        // to meet the necessary pre-conditions of this function.
        assert(x >= 0);

        // Call the overridden function in the subtype.
        f_impl(x);
    }

protected:
    // Overridden by a boatload of subtypes which implement
    // this non-virtual interface.
    virtual void f_impl(int x) = 0;
};

এই ক্ষেত্রে, সম্ভবত fকোডবেসে এক হাজার জায়গা দ্বারা ডাকা হয়, যখন f_implএকশত সাবক্লাস দ্বারা ওভাররাইড করা হয়।

কল করা সমস্ত 1000 জায়গায় fবা ওভাররাইড করা সমস্ত 100 টি স্থানে এই ধরণের সুরক্ষা চেক করা কঠিন হবে f_impl

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

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

এটি অত্যন্ত কার্যকর যদি আপনি এই কাজটি আগে থেকে না করেন assertএবং বুঝতে পেরেছিলেন যে পরে কোডবেজে কিছু এলোমেলো জায়গাগুলি নেতিবাচক মানগুলির সাথে সংঘটিত হচ্ছে f


0

প্রথম: বেস শ্রেণীর একাধিক অনুলিপি (একটি সি ++ ইস্যু) এবং বেস এবং উত্পন্ন শ্রেণীর মধ্যে টাইট মিলন।

দ্বিতীয়: বিমূর্ত ইন্টারফেস থেকে একাধিক উত্তরাধিকার


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