উত্তরাধিকার বনাম সমষ্টি [বন্ধ]


151

কোনও অবজেক্ট-ওরিয়েন্টেড সিস্টেমে কীভাবে কোডটি সর্বোপরি প্রসারিত, বর্ধন এবং পুনঃব্যবহার করা যায় সে সম্পর্কে দুটি চিন্তাভাবনা বিদ্যালয় রয়েছে:

  1. উত্তরাধিকার: একটি সাবক্লাস তৈরি করে একটি শ্রেণীর কার্যকারিতা প্রসারিত করুন। নতুন কার্যকারিতা সরবরাহ করার জন্য সাবক্লাসে সুপারক্লাস সদস্যদের ওভাররাইড করুন। সাবক্লাসগুলিকে "ফিল-ইন-দ্য ব্ল্যাকস" করতে বাধ্য করার জন্য পদ্ধতিগুলি বিমূর্ত / ভার্চুয়াল তৈরি করুন যখন সুপার ক্লাস একটি নির্দিষ্ট ইন্টারফেস চায় তবে এর বাস্তবায়ন সম্পর্কে অজ্ঞেয় থাকে।

  2. সমষ্টি: অন্যান্য ক্লাস নিয়ে এবং তাদেরকে একটি নতুন শ্রেণিতে সংযুক্ত করে নতুন কার্যকারিতা তৈরি করুন। অন্যান্য কোডের সাথে আন্তঃব্যবহারের জন্য এই নতুন শ্রেণিতে একটি সাধারণ ইন্টারফেস সংযুক্ত করুন।

প্রত্যেকের সুবিধা, ব্যয় এবং পরিণতিগুলি কী কী? অন্য বিকল্প আছে?

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


9
দুর্দান্ত প্রশ্ন, দুর্ভাগ্যক্রমে আমার এখন পর্যাপ্ত সময় নেই।
টুন ক্রিজেতে

4
একটি উত্তরের চেয়ে দ্রুত উত্তর দেওয়া ভাল ... আমি আমার নিজের প্রশ্নটি দেখছি তাই আমি আপনাকে কমপক্ষে ভোট দেব :
ক্রেগ ওয়াকার

উত্তর:


181

এটি কোনটি সর্বোত্তম তা নয় তবে কখন কী ব্যবহার করবেন তা নয়।

'সাধারণ' ক্ষেত্রে আমাদের উত্তরাধিকার বা সমষ্টি প্রয়োজন কিনা তা জানতে একটি সাধারণ প্রশ্নই যথেষ্ট।

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

তবে একটি বড় ধূসর অঞ্চল আছে। সুতরাং আমাদের আরও কয়েকটি কৌশল প্রয়োজন।

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

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

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

একটি উদাহরণ যোগ করা যাক। আমাদের পদ্ধতি সহ একটি 'কুকুর' রয়েছে: 'খাওয়া', 'হাঁটা', 'বার্ক', 'খেলুন'।

class Dog
  Eat;
  Walk;
  Bark;
  Play;
end;

আমাদের এখন একটি ক্লাস 'ক্যাট' দরকার, এর জন্য 'খাওয়া', 'ওয়াক', 'পুর' এবং 'খেলুন' দরকার। তাই প্রথমে এটি একটি কুকুরের কাছ থেকে প্রসারিত করার চেষ্টা করুন।

class Cat is Dog
  Purr; 
end;

ঠিক আছে, তবে অপেক্ষা করুন। এই বিড়ালটি বার্ক করতে পারে (বিড়াল প্রেমীরা আমাকে তার জন্য হত্যা করবে)। এবং একটি ঝাঁকুনি বিড়াল মহাবিশ্বের নীতি লঙ্ঘন করে। সুতরাং আমাদের বার্ক পদ্ধতিটি ওভাররাইড করা দরকার যাতে এটি কিছু না করে।

class Cat is Dog
  Purr; 
  Bark = null;
end;

ঠিক আছে, এটি কাজ করে তবে এটি দুর্গন্ধযুক্ত। সুতরাং একত্রিত করার চেষ্টা করা যাক:

class Cat
  has Dog;
  Eat = Dog.Eat;
  Walk = Dog.Walk;
  Play = Dog.Play;
  Purr;
end;

ঠিক আছে, এটি দুর্দান্ত। এই বিড়ালটি আর ঘেউ ঘেউ করে না, এমনকি নীরবও না। তবে এখনও এটির একটি অভ্যন্তরীণ কুকুর আছে যা বাইরে বেরিয়ে আসতে চায়। সুতরাং এর সমাধান নম্বর তিনটি চেষ্টা করে দেখুন:

class Pet
  Eat;
  Walk;
  Play;
end;

class Dog is Pet
  Bark;
end;

class Cat is Pet
  Purr;
end;

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


5
"ক্লাসের প্রায় সমস্ত কার্যকারিতা পুনরায় ব্যবহার" হ'ল আমি আসলে উত্তরাধিকারকে পছন্দ করি। আমি আসলে যা চাই তা হ'ল এমন একটি ভাষা যা সহজেই "এই নির্দিষ্ট পদ্ধতির জন্য এই সমষ্টিগত বস্তুর প্রতিনিধি" বলতে সক্ষম হয়; এটি উভয় বিশ্বের সেরা।
ক্রেগ ওয়াকার

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

2
উদ্দেশ্য সি সি প্রোটোকল ব্যবহার করে যা আপনাকে সিদ্ধান্ত দেয় যে আপনার ফাংশনটি প্রয়োজনীয় বা optionচ্ছিক।
cantfindaname88

1
একটি বাস্তব উদাহরণ সহ দুর্দান্ত উত্তর। আমি পোষা ক্লাসকে একটি পদ্ধতি বলে ডিজাইন করব makeSoundএবং প্রতিটি সাবক্লাসকে তাদের নিজস্ব ধরণের শব্দ প্রয়োগ করতে দেব। এটি তখন এমন পরিস্থিতিতে সহায়তা করবে যেখানে আপনার অনেক পোষা প্রাণী রয়েছে এবং ঠিক আছে for_each pet in the list of pets, pet.makeSound
ব্লুংহো


27

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

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


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

আমি এই পদ্ধতির পছন্দ করি না, এটি আরও রচনা সম্পর্কে
আলিরেজা রহমানি খলিলি

15

এখানে আমার সবচেয়ে সাধারণ যুক্তি:

যে কোনও অবজেক্ট-ভিত্তিক সিস্টেমে যে কোনও শ্রেণির দুটি অংশ রয়েছে:

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

  2. এর বাস্তবায়ন : "পর্দার অন্তরালে" কাজ করে যা বস্তু তার ইন্টারফেসটি সন্তুষ্ট করতে এবং কার্যকারিতা সরবরাহ করে। এটি সাধারণত বস্তুর কোড এবং সদস্য ডেটা।

ওওপি এর অন্যতম মৌলিক নীতি হ'ল বাস্তবায়নটি শ্রেণীর মধ্যে আবদ্ধ (যেমন: লুকানো) থাকে; বাইরের লোকদের একমাত্র জিনিসটি হ'ল ইন্টারফেস।

যখন একটি সাবক্লাস একটি সাবক্লাস থেকে উত্তরাধিকার সূত্রে প্রাপ্ত হয়, সাধারণত এটি বাস্তবায়ন এবং ইন্টারফেস উভয়ই উত্তরাধিকার সূত্রে প্রাপ্ত হয় । এর পরিবর্তে এর অর্থ হল যে আপনি উভয়কেই আপনার ক্লাসের প্রতিবন্ধকতা হিসাবে গ্রহণ করতে বাধ্য করেছেন।

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

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


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

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

আপনি কি মনে করেন, এই দৃশ্যে সমষ্টিটি আরও ভাল? পুস্তক একটি SellingItem, একটি DigitalDisc একটি SelliingItem হয় codereview.stackexchange.com/questions/14077/...
LCJ

11

আমি "একটি" বনাম "আছে" একটি উত্তর দিয়েছি : কোনটি ভাল?

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

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

সেগুলি দৃ strong় সূত্র যে একত্রিতাই সেই ক্ষেত্রে ভাল পছন্দ।


6

আমি দেখতে পাচ্ছি অনেকগুলি "একটি-বনামের-এর-এর-এর; তারা ধারণাগতভাবে পৃথক" এই এবং সম্পর্কিত প্রশ্নগুলির প্রতিক্রিয়া।

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

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

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

সুতরাং, যখনই আপনাকে কোনও বা অন্যটিকে বেছে নিতে হবে, উত্তরাধিকারের বিরুদ্ধে আপনার পক্ষে নিখুঁত যুক্তি রয়েছে:

  1. আপনার পছন্দ সম্ভবত এক পর্যায়ে ভুল হতে হবে
  2. একবারে এই পছন্দটি তৈরি করা কঠিন is
  3. উত্তরাধিকার হ'ল এটি আরও বাধা হওয়ায় একটি খারাপ পছন্দ হতে পারে।

সুতরাং, আমি একত্রিতকরণ বেছে নেওয়ার প্রবণতা করি - এমনকি যখন কোনও সম্পর্ক শক্তিশালী বলে মনে হয়।


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

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

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

আমার মনে, সমষ্টি + ইন্টারফেসগুলি উত্তরাধিকার / সাবক্লাসিংয়ের বিকল্প; আপনি একীকরণের ভিত্তিতে পলিমারফিজম করতে পারবেন না।
ক্রেগ ওয়াকার

3

প্রশ্নটি সাধারণত সংশ্লেষ বনাম উত্তরাধিকার হিসাবে চিহ্নিত হয় এবং এটি এখানে আগে জিজ্ঞাসা করা হয়েছিল।


ঠিক তুই .. মজার যে এসও যে কোনও একটি সম্পর্কিত প্রশ্ন হিসাবে এটি দেয় নি।
ক্রেগ ওয়াকার

2
SO অনুসন্ধান এখনও বড় সময়
চুষছে

একমত। এই কারণেই আমি এটি বন্ধ করিনি। এটি, এবং অনেক লোক ইতিমধ্যে এখানে উত্তর দিয়েছিল।
বিল

1
2 টি প্রশ্ন (এবং তাদের প্রতিক্রিয়া) 1 তে রোল করার জন্য এসওর একটি বৈশিষ্ট্য প্রয়োজন
ক্রেগ ওয়াকার

3

আমি এটি মূল প্রশ্নের উপরে একটি মন্তব্য করতে চেয়েছিলাম, তবে 300 টি অক্ষর কামড় দেয় [; <)।

আমি মনে করি আমাদের সাবধান হওয়া দরকার। প্রথমত, প্রশ্নটিতে তৈরি দুটি নির্দিষ্ট উদাহরণের চেয়ে আরও স্বাদ রয়েছে।

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

উদাহরণস্বরূপ, আপনি কী সম্পাদন করতে চলেছেন, কী শুরু করার জন্য আপনার কাছে উপলব্ধ রয়েছে এবং বাধাগুলি কী কী?

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

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

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


2

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

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

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


2

আমি মনে করি এটি কোনও / বা বিতর্ক নয়। এটা ঠিক যে:

  1. is-a (উত্তরাধিকার) সম্পর্কগুলি হ'ল-এ (রচনা) সম্পর্কের চেয়ে কম প্রায়ই ঘটে।
  2. উত্তরাধিকার সঠিকভাবে পাওয়া সঠিক, এমনকি এটি ব্যবহার করার উপযুক্ত হলেও, তাই যথাযথ অধ্যবসায় গ্রহণ করতে হবে কারণ এটি এনক্যাপসুলেশনটি ভেঙে ফেলতে পারে, বাস্তবায়নকে সামনে রেখে এবং আরও শক্তিশালী সংযোগকে উত্সাহিত করতে পারে।

উভয়েরই জায়গা আছে তবে উত্তরাধিকার ঝুঁকিপূর্ণ।

যদিও অবশ্যই এটি একটি বর্গ শেপ 'থাকার-একটি' পয়েন্ট এবং একটি স্কোয়ার ক্লাসগুলি বোধগম্য হবে না। এখানে উত্তরাধিকার নির্ধারিত।

এক্সটেনসিবল কিছু ডিজাইনের চেষ্টা করার সময় লোকেরা প্রথমে উত্তরাধিকার নিয়ে ভাবার প্রবণতা পোষণ করে, এটাই ভুল।


1

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

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

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


0

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

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

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