একাধিক উত্তরাধিকার একক দায়িত্ব নীতি লঙ্ঘন করে?

Question

আপনার যদি এমন একটি শ্রেণি থাকে যা দুটি স্বতন্ত্র শ্রেণির উত্তরাধিকার সূত্রে প্রাপ্ত হয়, তার অর্থ এই নয় যে আপনার উপক্লাসটি স্বয়ংক্রিয়ভাবে (কমপক্ষে) 2 টি জিনিস করে, প্রতিটি সুপারক্লাসের একটি?

আমি বিশ্বাস করি আপনার যদি একাধিক ইন্টারফেস উত্তরাধিকার থাকে তবে কোনও পার্থক্য নেই।

সম্পাদনা: পরিষ্কার হওয়ার জন্য, আমি বিশ্বাস করি যে যদি একাধিক শ্রেণীর সাবক্লাসিং এসআরপি লঙ্ঘন করে তবে একাধিক (নন-মার্কার বা বেসিক ইন্টারফেস (যেমন তুলনীয়)) ইন্টারফেসগুলি এসআরপি লঙ্ঘন করে।

Comments

কেবল স্পষ্ট করে বলতে গেলে, আপনিও বিশ্বাস করেন যে একাধিক ইন্টারফেস প্রয়োগ করা এসআরপি লঙ্ঘন করে?

আমি বিশ্বাস করি যে যদি একাধিক ক্লাসের সাবক্লাসিং এসআরপি লঙ্ঘন করে, তবে একাধিক (নন-মার্কার) ইন্টারফেস প্রয়োগ করে এসআরপিও লঙ্ঘন করে।

— m3th0dman

আমি এই প্রশ্নটি উত্সাহিত করব, তবে আপনি প্রশ্নটিতে আপনার মতামত এম্বেড করেছেন, যার সাথে আমি একমত নই।

— নিকোল

@ নিকসি: আমি আমার মতামত বলিনি (আপনার উপরের মন্তব্যটি পড়া উচিত ছিল); প্রশ্নটি আরও পরিষ্কার করার জন্য আমি সম্পাদনা করব।

— m3th0dman

@ নিকসি আমার কোন মতামত নেই, এজন্যই আমি জিজ্ঞাসা করেছি। আমি কেবল বলেছি যে দুটিই সম্পর্কিত (ইন্টারফেসের উত্তরাধিকার এবং শ্রেণীর উত্তরাধিকার); যদি এটি শ্রেণীর উত্তরাধিকারের জন্য লঙ্ঘন করে তবে এটি ইন্টারফেসের উত্তরাধিকারের জন্যও লঙ্ঘন করে, যদি এটি একটির পক্ষে না হয় তবে তা অন্যটির পক্ষে লঙ্ঘনও করে না। এবং আমি আপ

— উত্থাপনের

Answer 1

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

আপনি আপনার শ্রেণি এবং ইন্টারফেস দুটি প্রধান গ্রুপে বিভক্ত করতে পারেন - এটি আপনার সিস্টেমের প্রয়োজনীয় জটিলতাগুলিকে সম্বোধন করে এবং এর দুর্ঘটনাজনিত জটিলতাগুলিকে সম্বোধন করে। যদি একাধিক "প্রয়োজনীয় জটিলতা" শ্রেণি থেকে উত্তরাধিকারী হয় তবে এটি খারাপ; যদি আপনি একটি "অপরিহার্য" এবং এক বা একাধিক "দুর্ঘটনাজনিত" শ্রেণি থেকে উত্তরাধিকারী হন তবে তা ঠিক।

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

class BillingCycleInvoice : public BillingCycle, public Invoice {
};

এটি খারাপ: BillingCycleInvoiceএটি সিস্টেমের প্রয়োজনীয় জটিলতার সাথে সম্পর্কিত বলে আপনার একটি মিশ্র দায়িত্ব রয়েছে।

অন্যদিকে, যদি আপনি এর মতো উত্তরাধিকারী হন

class PersistentInvoice : public Invoice, public PersistentObject {
};

আপনার ক্লাসটি ঠিক আছে: প্রযুক্তিগতভাবে, এটি একবারে দুটি উদ্বেগকে সরবরাহ করে, তবে যেহেতু এর মধ্যে কেবল একটির প্রয়োজনীয়তা রয়েছে তাই আপনি দুর্ঘটনাকবলিত উত্তরাধিকার সূত্রে "ব্যবসায় করার ব্যয়" হিসাবে লিখতে পারেন।

Comments

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

সিম্পলস্ট হ'ল যদি কোনও নতুন ইন্টারফেস প্রয়োগের জন্য শ্রেণীর কার্যকারিতা সম্পূর্ণ করতে হয় তবে তা নয়। তবে যদি এটি নতুন দায়িত্ব যুক্ত করে অন্য কোনও শ্রেণির সাথে ইন্টারফেস প্রয়োগ করে তবে নির্ভরতা হিসাবে ইনজেকশন কখনই এসআরপি লঙ্ঘন করে না

— রামানকিংডো

Answer 2

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

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

Answer 3

কিছুটা। এসআরপি-র মূল নীতিটি ফোকাস করা যাক:

একটি শ্রেণীর পরিবর্তনের কেবল একটি কারণ থাকতে হবে।

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

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

Answer 4

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

তার মানে এই নয় যে শ্রেণীর তিনটি দায়িত্ব রয়েছে। এর অর্থ হ'ল কোনও ব্যবহারকারীর মডেল করার দায়িত্বের অংশটির জন্য সিরিয়ালাইজেশন এবং অধ্যবসায় সমর্থন করা প্রয়োজন।

Answer 5

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

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

Answer 6

আমি মনে করি এটি নির্ভর করে আপনি কীভাবে দায়িত্বটি সংজ্ঞায়িত করেন। ক্লাসিক আইস্ট্রিম উদাহরণে এটি এসআরপি লঙ্ঘন করে না। আইওস্ট্রিম একটি দ্বি নির্দেশমূলক স্ট্রিম পরিচালনার জন্য দায়বদ্ধ।

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