সি ++: শ্রেণিটির নিজস্ব নির্ভরতা বা পর্যবেক্ষণ করা উচিত?

Question

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

class Foobar {
    Widget widget;
    public:
    Foobar() : widget(blah blah blah) {}
    // or
    std::unique_ptr<Widget> widget;
    public:
    Foobar() : widget(std::make_unique<Widget>(blah blah blah)) {}
    (…)
};

এবং আমরা সব প্রস্তুত এবং সম্পন্ন করা চাই। দুর্ভাগ্যক্রমে, আজ জাভা বাচ্চারা এটি দেখার পরে এবং ঠিকই এটি দম্পতিরা Foobarএবং Widgetএকসাথে দেখে হাসবে will সমাধানটি আপাতদৃষ্টিতে সহজ: Foobarক্লাসের বাইরে নির্ভরতা নির্মাণের জন্য নির্ভরতা ইনজেকশন প্রয়োগ করুন । তবে তারপরে, সি ++ আমাদের নির্ভরতাগুলির মালিকানা সম্পর্কে চিন্তা করতে বাধ্য করে। তিনটি সমাধান মাথায় আসে:

অনন্য পয়েন্টার

class Foobar {
    std::unique_ptr<Widget> widget;
    public:
    Foobar(std::unique_ptr<Widget> &&w) : widget(w) {}
    (…)
}

FoobarWidgetএটির একমাত্র মালিকানা দাবি করা হয়েছে। এর নিম্নলিখিত সুবিধা রয়েছে:

1. পারফরম্যান্সের উপর প্রভাব নগণ্য।
2. এটি নিরাপদ, যেমনটি Foobarআজীবন নিয়ন্ত্রণ করে Widget, তাই এটি নিশ্চিত করে তোলে যে Widgetহঠাৎ অদৃশ্য হয়ে যাবে না।
3. এটি নিরাপদ যা Widgetফাঁস হবে না এবং যখন প্রয়োজন হবে না তখন সঠিকভাবে ধ্বংস হয়ে যাবে।

তবে, এটি ব্যয় করে আসে:

1. এটি কীভাবে Widgetদৃষ্টান্তগুলি ব্যবহার করা যায় তার উপর বিধিনিষেধ স্থাপন করে , যেমন কোনও স্ট্যাক-বরাদ্দ Widgetsব্যবহার করা যায় না, Widgetভাগ করা যায় না।

ভাগ করা পয়েন্টার

class Foobar {
    std::shared_ptr<Widget> widget;
    public:
    Foobar(const std::shared_ptr<Widget> &w) : widget(w) {}
    (…)
}

এটি সম্ভবত নিকটতম সমতুল্য ও জাভা এবং অন্যান্য আবর্জনা সংগ্রহ করা ভাষা। সুবিধাদি:

1. আরও সার্বজনীন, কারণ এটি ভাগ করে নেওয়ার নির্ভরতা।
2. সমাধানের সুরক্ষা (পয়েন্ট 2 এবং 3) বজায় রাখে unique_ptr।

অসুবিধা:

1. কোনও ভাগীকরণ জড়িত না হলে সম্পদ অপচয় করে।
2. তবুও গাদা বরাদ্দ প্রয়োজন এবং স্ট্যাক-বরাদ্দ বস্তুগুলি নিষ্ক্রিয় করে।

সরল ওল 'পর্যবেক্ষণ পয়েন্টার

class Foobar {
    Widget *widget;
    public:
    Foobar(Widget *w) : widget(w) {}
    (…)
}

শ্রেণীর ভিতরে কাঁচা পয়েন্টার রাখুন এবং মালিকানার বোঝা অন্য কারও কাছে স্থানান্তর করুন। পেশাদাররা:

1. এটি পেতে পারেন হিসাবে সহজ।
2. সর্বজনীন, কেবল যে কোনও গ্রহণ করে Widget।

কনস:

1. আর নিরাপদ নয়।
2. অন্য সত্তা উভয় মালিকানা জন্য দায়ী প্রবর্তন Foobarএবং Widget।

কিছু ক্রেজি টেম্পলেট রূপান্তরকারী

কেবলমাত্র আমি যে সুবিধাটি ভাবতে পারি তা হ'ল আমি আমার সমস্ত সফটওয়্যার ফুটে উঠার সময় খুঁজে পেলাম না books সমস্ত বই পড়তে;

আমি তৃতীয় সমাধানের দিকে ঝুঁকেছি, কারণ এটি সর্বজনীন, কিছু কিছু হলেও পরিচালিত Foobarsকরতে হয়, তাই পরিচালন Widgetsকরা সহজ পরিবর্তন। তবে, কাঁচা পয়েন্টার ব্যবহার করা আমাকে বিরক্ত করে, অন্যদিকে স্মার্ট পয়েন্টার সমাধানটি আমার কাছে ভুল অনুভব করে, কারণ তারা নির্ভরতার গ্রাহককে সেই নির্ভরতা কীভাবে তৈরি করা হয় তা সীমাবদ্ধ করে দেয়।

আমি কিছু অনুপস্থিত করছি? অথবা সি ++ তে কেবল নির্ভরতা ইনজেকশন তুচ্ছ নয়? শ্রেণীর নিজস্ব নির্ভরতা থাকা উচিত বা কেবল সেগুলি পর্যবেক্ষণ করা উচিত?

Comments

শুরু থেকেই, আপনি যদি সি ++ 11 এর অধীন সংকলন করতে পারেন এবং / বা কখনই না, ক্লাসে সংস্থানগুলি পরিচালনা করার উপায় হিসাবে প্লেইন পয়েন্টার থাকা এখন আর প্রস্তাবিত উপায় নয়। যদি ফুবার শ্রেণিটি কেবলমাত্র সংস্থানটির মালিক এবং যদি ফুবার সুযোগের বাইরে চলে যায়, তবে সেটাই std::unique_ptrহল উপায়। আপনি std::move()কোনও সংস্থার মালিকানা উচ্চ শ্রেণি থেকে শ্রেণিতে স্থানান্তর করতে ব্যবহার করতে পারেন ।

— অ্যান্ডি

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

— el.pescado

@ el.pescado জাভাতেও একই সমস্যা রয়েছে, মেমরি একমাত্র সম্পদ নয়। উদাহরণস্বরূপ ফাইল এবং সংযোগ রয়েছে। জাভাতে এটি সমাধান করার স্বাভাবিক উপায় হ'ল একটি ধারক যা এতে থাকা সমস্ত বস্তুর জীবনচক্র পরিচালনা করে। অতএব আপনাকে কোনও ডিআই কনটেইনারে থাকা সামগ্রীতে এটি নিয়ে চিন্তা করতে হবে না। এটি সি ++ অ্যাপ্লিকেশনগুলির জন্যও কাজ করতে পারে যদি ডিআই কন্টেইনারটির জন্য কোনও উপায় থাকে যে কখন কোন লাইফসাইकल পর্যায়ে যেতে হবে তা জানার উপায় রয়েছে know

— স্পেসট্রকার

অবশ্যই, আপনি এটি সমস্ত জটিলতা ছাড়াই পুরানো কায়দায় করতে পারেন এবং কোড থাকতে পারে যা কাজ করে এবং এটি বজায় রাখা সহজ way (নোট করুন যে জাভা ছেলেরা হাসতে পারে, তবে তারা সবসময় রিফ্যাক্টরিংয়ের কাজ চালিয়ে যায়, তাই

— ডিকোপলিং

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

Answer 1

আমি এটি একটি মন্তব্য হিসাবে লিখতে চেয়েছিলাম, তবে এটি খুব দীর্ঘ হয়েছে।

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

আপনার ব্যবহার করা উচিত std::unique_ptr<Widget>বা না std::shared_ptr<Widget>, এটি সিদ্ধান্ত নেওয়ার উপর নির্ভর করে এবং আপনার কার্যকারিতা থেকে আসে।

ধরে নেওয়া যাক আপনার একটি রয়েছে Utilities::Factoryযা আপনার ব্লক তৈরির জন্য দায়ী Foobar। ডিআই নীতি অনুসরণ করে আপনার ইনস্ট্রাক্টটির প্রয়োজন হবে Widget, Foobarএর কনস্ট্রাক্টর ব্যবহার করে ইনজেক্ট করতে , যার অর্থ যেকোন একটি Utilities::Factoryপদ্ধতির অভ্যন্তর, উদাহরণস্বরূপ createWidget(const std::vector<std::string>& params), আপনি উইজেট তৈরি করেন এবং এটি Foobarবস্তুতে ইনজেক্ট করেন ।

এখন আপনার কাছে একটি Utilities::Factoryপদ্ধতি রয়েছে, যা Widgetবস্তুটি তৈরি করেছে । এর অর্থ কি, পদ্ধতিটি মুছে ফেলার জন্য আমাকে দায়ী করা উচিত? অবশ্যই না. এটি আপনাকে কেবল উদাহরণ তৈরি করার জন্য রয়েছে।

---

আসুন কল্পনা করুন, আপনি একটি অ্যাপ্লিকেশন বিকাশ করছেন, যার একাধিক উইন্ডো থাকবে। প্রতিটি উইন্ডো Foobarক্লাস ব্যবহার করে প্রতিনিধিত্ব করা হয় , সুতরাং বাস্তবে Foobarএকটি নিয়ামকের মতো কাজ করে।

নিয়ামক সম্ভবত আপনার কিছু ব্যবহার করতে হবে Widgetএবং আপনাকে নিজেকে জিজ্ঞাসা করতে হবে:

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

std::shared_ptr<Widget> যাবার উপায়

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

এখানেই std::unique_ptr<Widget>এর সিংহাসন দাবি করতে আসে।

---

হালনাগাদ:

আজীবন সমস্যা সম্পর্কে আমি সত্যিই @ ডমিনিক এমসিডোনেল এর সাথে একমত নই । সম্পূর্ণভাবে মালিকানা হস্তান্তর করার জন্য আহ্বান জানানো std::moveহয়েছে std::unique_ptr, সুতরাং আপনি যদি object Aকোনও পদ্ধতিতে একটি তৈরি করে এবং এটি object Bনির্ভরতা হিসাবে অন্যকে দিয়ে দেন তবে সুযোগের বাইরে গেলেই object Bএখন সংস্থানটির উত্সের জন্য দায়বদ্ধ object Aথাকবেন এবং সঠিকভাবে এটি মুছবেন object B।

Comments

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

— el.pescado

উদাহরণস্বরূপ, আমার যে সমস্যাটি রয়েছে তা unique_ptrহ'ল ইউনিট টেস্টিং (ডিআই কে টেস্টিং-ফ্রেন্ডলি হিসাবে বিজ্ঞাপন দেওয়া হয়): আমি পরীক্ষা করতে চাই Foobar, তাই আমি এটি তৈরি Widgetকরতে পারি Foobar, অনুশীলন Foobarকরতে পারি এবং তারপরে আমি পরিদর্শন করতে চাই Widget, তবে যতক্ষণ না Foobarএটি প্রকাশ না করে আমি পারব এটা যেহেতু টি দাবি করেছে Foobar।

— el.pescado

@ el.pescado আপনি দুটি জিনিস একসাথে মিশ্রিত করছেন। আপনি অ্যাক্সেসযোগ্যতা এবং মালিকানা মিশ্রিত করছেন। শুধু কারণ Foobarরিসোর্স মানে না, আর কেউ এটি ব্যবহার করা উচিত মালিক। আপনি এমন একটি Foobarপদ্ধতি প্রয়োগ Widget* getWidget() const { return this->_widget.get(); }করতে পারেন যা আপনাকে কাজ করতে পারে এমন কাঁচা পয়েন্টার ফিরিয়ে দেবে। আপনি যখন Widgetক্লাসটি পরীক্ষা করতে চান তখন আপনি নিজের ইউনিট পরীক্ষার জন্য একটি ইনপুট হিসাবে এই পদ্ধতিটি ব্যবহার করতে পারেন ।

— অ্যান্ডি

ভাল পয়েন্ট, যে বোঝার।

— el.pescado

আপনি যদি একটি শেয়ারড_পিটারকে একটি অনন্য_পিটারে রূপান্তর করেন তবে আপনি কীভাবে অনন্য_র গ্যারান্টি দিতে চান ???

— একনকাগুয়া

Answer 2

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

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

হালনাগাদ

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

Answer 3

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

দ্বিতীয়: এই প্রশ্নের কোনও সাধারণ উত্তর নেই - এটি প্রয়োজনীয়তাগুলি কী তার উপর নির্ভর করে!

FooBar এবং উইজেট সংযুক্ত সম্পর্কে সমস্যা কি? FooBar একটি উইজেট ব্যবহার করতে চায় এবং যদি প্রতিটি FooBar দৃষ্টান্ত সর্বদা নিজস্ব এবং একই উইজেটটি থাকে তবে এটিকে একত্রে ছেড়ে দিন ...

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

namespace WidgetFactory
{
    Widget* create(int, int)
    {
        return 0;
    }
    Widget* create(int, bool, long)
    {
        return 0;
    }
}
class FooBar
{
public:
    template < typename ...Arguments >
    FooBar(Arguments... arguments)
        : mWidget(WidgetFactory::create(arguments...))
    {
    }
    ~FooBar()
    {
        delete mWidget;
    }
private:
    Widget* mWidget;
};

FooBar foobar1(10, 12);
FooBar foobar2(51, true, 54L);

পছন্দ করি?

অবশ্যই, সেখানে হয় যেমন আপনি একটি সময় পর্যন্ত আগে কোনো FOOBAR উদাহরণস্বরূপ বিদ্যমান, যদি তুমি চাও বা উইজেট, ..., বা শুধু পুনরায় ব্যবহার করার জন্য প্রয়োজন এ উইজেট তৈরি করা প্রয়োজন - কারণ যখন আপনি চান বা উভয় শ্রেণীর decouple করার প্রয়োজনীয়তা কারণ বর্তমান সমস্যার জন্য এটি আরও উপযুক্ত (উদাহরণস্বরূপ, যদি উইজেটটি জিইউআই উপাদান হয় এবং ফুবার একটি / নাও হতে পারে)।

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

Comments

সি ++ তে classস্থিতিশীল পদ্ধতি ব্যতীত এসএস ব্যবহার করবেন না , এমনকি এটি আপনার উদাহরণ হিসাবে কেবল একটি কারখানা। এটি ওও নীতির লঙ্ঘন করে। পরিবর্তে নেমস্পেস ব্যবহার করুন এবং সেগুলি ব্যবহার করে আপনার ফাংশনগুলি গোষ্ঠী করুন।

— অ্যান্ডি

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

— অ্যাকনকাগুয়া

Answer 4

আপনি কমপক্ষে আরও দুটি বিকল্প মিস করছেন যা আপনার জন্য সি ++ এ উপলভ্য:

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

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

কোন বিকল্পটি সবচেয়ে উপযুক্ত তা আপনার ব্যবহারের ক্ষেত্রে নির্ভর করে, একটি সাধারণ উত্তর দেওয়া শক্ত। আপনার যদি কেবল স্ট্যাটিক পলিমারফিজম প্রয়োজন তবে আমি বলব যে টেমপ্লেটগুলি সর্বাধিক সি ++ উপায় way

Answer 5

আপনি চতুর্থ সম্ভাব্য উত্তরটিকে অগ্রাহ্য করেছেন, যা নির্ভর করে ইনজেকশনের মাধ্যমে আপনি পোস্ট করা প্রথম কোডটি (মুল্য অনুসারে সদস্যকে স্টোর করার "" ভাল দিন ") একত্রিত করে:

class Foobar {
    Widget widget;
public:
    Foobar(Widget w) // pass w by value
     : widget{ std::move(w) } {}
};

ক্লায়েন্ট কোড তারপর লিখতে পারেন:

Widget w;
Foobar f1{ w }; // default: copy w into f1
Foobar f2{ std::move(w) }; // move w into f2

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

আপনি ধারণাগত মানদণ্ডও ব্যবহার করতে পারেন ("একটি গাড়িতে চার চাকা রয়েছে" বনাম "" একটি গাড়িতে চার চাকা ব্যবহার করা হয় যা চালককে সাথে আনতে হবে))।

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

Comments

এটি বহুত্বপূর্ণ আচরণকে অন্তর্ভুক্ত করে, যা অতিরিক্ত মূল্যকে কঠোরভাবে সীমাবদ্ধ করে।

— el.pescado

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

— বহুবর্ষগত