গেমটি বিকাশের জন্য আমার কী সম্ভব অবাস্তব উত্তরাধিকার ব্যবহার করা এড়ানো উচিত?


36

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

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

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

আমি একই ক্ষেত্র, সাধারণভাবে বিভিন্ন ক্লাস, ব্যবহৃত সংজ্ঞায়িত করতে চাই না মত AudioSource/ Rigidbody/ Animatorও সদস্য ক্ষেত্র আমি সংজ্ঞায়িত প্রচুর fireRate, damage, range, spreadইত্যাদি। এছাড়াও কিছু ক্ষেত্রে, কিছু পদ্ধতি ওভাররাইট করা যেতে পারে। সুতরাং আমি সেই ক্ষেত্রে ভার্চুয়াল পদ্ধতিগুলি ব্যবহার করছি, যাতে মূলত আমি পিতামাত্ত শ্রেণীর থেকে পদ্ধতিটি ব্যবহার করে সেই পদ্ধতিটি আহ্বান করতে পারি, তবে যুক্তিটি যদি শিশুটির মধ্যে আলাদা হওয়া উচিত তবে আমি ম্যানুয়ালি সেগুলি ওভাররাইড করে দিয়েছি।

তাহলে, এই সমস্ত জিনিসকে খারাপ অভ্যাস হিসাবে ছেড়ে দেওয়া উচিত? পরিবর্তে আমার ইন্টারফেস ব্যবহার করা উচিত?


30
"এখানে অনেক সুবিধা রয়েছে এবং আমি যে প্যাটার্নটি উপভোগ করি তা হ'ল বহুবর্ষ"। পলিমারফিজম কোনও নিদর্শন নয়। এটি আক্ষরিকভাবে OOP এর সম্পূর্ণ পয়েন্ট point সাধারণ ক্ষেত্র ইত্যাদির মতো অন্যান্য জিনিস কোড অনুলিপি বা উত্তরাধিকার ছাড়াই সহজেই অর্জন করা যায়।
কিউবিক

3
যে ব্যক্তি আপনাকে ইন্টারফেসের পরামর্শ দিয়েছিল তার উত্তরাধিকারের চেয়ে উত্তম কি আপনাকে কোনও যুক্তি দিয়েছিল? আমি কৌতুহলী.
হকার 65

1
@ কিউবিক আমি কখনও বলিনি যে পলিমারফিজম একটি নিদর্শন। আমি বলেছিলাম "... একটি প্যাটার্ন যা আমি সত্যিই উপভোগ করি তা হ'ল পলিমারফিজম"। এর অর্থ হ'ল আমি যে প্যাটার্নটি সত্যই উপভোগ করছি তা হল "পলিমারফিজম" ব্যবহার করা, পলিমারফিজমটি কোনও প্যাটার্ন নয়।
আধুনিক

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

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

উত্তর:


65

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

আপনার অ্যাপ্লিকেশন-স্তরের যুক্তিতে রচনাগুলির চেয়ে উত্তরাধিকারের পক্ষে পছন্দ করুন , ইউআই থেকে শুরু করে পরিষেবা পর্যন্ত সমস্ত কিছুই। উদাহরণ স্বরূপ,

Widget->Button->SpinnerButton অথবা

ConnectionManager->TCPConnectionManagerবনাম ->UDPConnectionManager

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

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


10
উত্তরাধিকার সূচিত করে না যে সমস্ত পদ্ধতি ভার্চুয়াল হবে। সুতরাং এটি স্বয়ংক্রিয়ভাবে কোনও পারফরম্যান্স ব্যয় নিয়ে যায় না। ভিটিবেল কেবল ভার্চুয়াল কল প্রেরণে ভূমিকা রাখে , ডেটা সদস্যদের অ্যাক্সেস না করে।
রুসলান

1
@ রাস্লান আমি আপনার মন্তব্যকে সামঞ্জস্য করতে 'মে' এবং 'ক্যান' শব্দ যুক্ত করেছি। অন্যথায়, উত্তরটি সংক্ষিপ্ত রাখার স্বার্থে, আমি খুব বেশি বিশদে যাইনি। ধন্যবাদ।
ইঞ্জিনিয়ার

7
P.S. The other reason we may favour composition in entity systems is ... performance: এটা কি সত্যি? @ লিনাইথ শো দ্বারা লিঙ্কিত উইকপিডিয়া পৃষ্ঠাটি দেখে, আপনার ইন্টারফেসের বিষয়টিকে রচনা করা দরকার। অতএব আপনি অন্য স্তরের ইন্ডিয়ারেশনের সাথে পরিচয় করিয়ে দেওয়ার সাথে সাথে আপনার (এখনও বা আরও বেশি) ভার্চুয়াল ফাংশন কল এবং আরও ক্যাশে মিস হয়েছে।
শিগগির

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

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

18

আপনি ইতিমধ্যে কয়েকটি সুন্দর উত্তর পেয়েছেন, তবে আপনার প্রশ্নের ঘরে যে বিশাল হাতি তা হ'ল:

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

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

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

কম সংযোগ

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

দুটি সত্তা মিলিত হওয়ার লক্ষণটি হ'ল অন্য যে কোনও উপায়ে পরিবর্তিত হলে তাদের মধ্যে একটি ভেঙে যায় (বা পরিবর্তিত হওয়া দরকার) need

উত্তরাধিকার মিলন বৃদ্ধি, স্পষ্টতই; বেস ক্লাস পরিবর্তন করে সমস্ত সাবক্লাস পরিবর্তন হয়।

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

উচ্চ সংহতি

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

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

কোনও সত্তা সংহত না হওয়ার লক্ষণটি হ'ল যদি এটি আরও বড় এবং বৃহত্তর হয়ে ওঠে, একই সাথে বেশ কয়েকটি দিকে শাখা করে।

উত্তরাধিকার হিসাবে এটি বর্ণনা করার সাথে একাত্মতা হ্রাস পায় - আপনার অস্ত্রের ক্লাসগুলি দিন শেষে, বড় অংশগুলি যারা আপনার অস্ত্রগুলির সমস্ত প্রকারের, অ-সম্পর্কিত দিকগুলি পরিচালনা করে।

ইন্টারফেস অপ্রত্যক্ষভাবে ইন্টারফেসের উভয় পক্ষের মধ্যে দায়িত্ব বিচ্ছিন্ন করে সংহতি বৃদ্ধি করে।

এখন কি করতে হবে

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

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


বিস্তারিত ব্যাখ্যার জন্য আপনাকে ধন্যবাদ। আমি কী মিস করছি তা বুঝতে এটি সত্যিই সহায়ক।
আধুনিক

13

উত্তরাধিকার অবশ্যই এড়ানো উচিত এই ধারণাটি ভুল।

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

আমাকে বলতে হবে যে আমি আপনার অস্ত্রের ক্লাস পছন্দ করি এবং এটিও একইভাবে করতে পারে। তবে আমি এখনই কোনও খেলা তৈরি করিনি ...

জেমস ট্রটার দ্বারা নির্দেশিত হিসাবে, রচনাটির কিছু সুবিধা থাকতে পারে, বিশেষত রানটাইমের সময় নমনীয়তায় অস্ত্র কীভাবে কাজ করে তা পরিবর্তন করতে। উত্তরাধিকারের মাধ্যমে এটি সম্ভব হবে তবে এটি আরও কঠিন।


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

3
@ জেমসট্রোটার এই মুহুর্তে, আমি বর্ডারল্যান্ডস এবং তার বন্দুকগুলি সম্পর্কে ভাবি এবং অবাক করি যে এটি কেবল এক উত্তরাধিকারের সাথে কি একজাতীয় হবে ...
বাল্ড্রিক

1
@ জেমস ট্রোটার আমি আশা করি যে এটি একটি উত্তর ছিল এবং কোনও মন্তব্য নয়।
ফারাপ

6

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

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

নীচে একটি গ্রেনেড লঞ্চার সহ একটি অ্যাসল্টরিফাল কী - হুম, কিছুটা শক্ত। আপনি গ্রেনাড লঞ্চারকে রাতের সময় শিকারের জন্য একটি টর্চলাইট দিয়ে প্রতিস্থাপন করতে পারেন?

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

একাধিক উত্তরাধিকার এই তুচ্ছ উদাহরণগুলির কিছুটা কিছুটা ঠিক করতে পারে তবে এটি নিজের সমস্যাগুলির সেট যোগ করে।

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


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

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

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

7
@ আধুনিক পরিচালক মিনক্রাফ্টে তারা Monsterএকটি সাবক্লাস তৈরি করেছেন WalkingEntity। তারপরে তারা কাটা যোগ করলেন। আপনি কতটা ভাল কাজ অনুমান?
ব্যবহারকারী 253751

1
@ ইমিবিস আপনার কি সেই সমস্যার সাথে কোনও রেফারেন্স বা অজানা লিঙ্ক আছে? গুগলিং মাইনক্রাফ্ট কীওয়ার্ডগুলি আমাকে ভিডিও লিঙ্কগুলিতে ডুবিয়ে দেয় ;-)
পিটার - মনিকা পুনরায়

3

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

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

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


যদি ইন্টারফেসগুলি কোনও ওওপি ভাষার প্রথম শ্রেণির নাগরিক হয় তবে আমি ভাবছি পাইথন, রুবি ...… ওওপি ভাষা না।
ব্ল্যাকজ্যাক

@BlackJack: ইন রুবি, ইন্টারফেস (যদি আপনি হবে হাঁস টাইপিং) অন্তর্নিহিত, এবং পরিবর্তে রচনা উত্তরাধিকার ব্যবহার দ্বারা প্রকাশ (এছাড়াও, এটি Mixins যার মধ্যে কোথাও রয়েছে যতটা আমি উদ্বিগ্ন) ...
AnoE

@ ব্ল্যাকজ্যাক "ইন্টারফেস" (ধারণা )টির প্রয়োজন নেই interface(ভাষার কীওয়ার্ড)।
কালেথ

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

2

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

উত্তরাধিকার বনাম রচনাটি হ'ল একটি প্রশ্ন vs ইন্টারফেসগুলি অন্য একটি (তৃতীয়) উপায়, কিছু পরিস্থিতিতে উপযুক্ত।

উত্তরাধিকার বা হ'ল যুক্তি: আপনি যখন নতুন ক্লাসটি ব্যবহার করছেন তখন পুরানো শ্রেণীর মতো (বাহ্যিকভাবে) সম্পূর্ণরূপে ব্যবহার করা হবে এবং নতুন ক্লাসটি জনসাধারণের কাছে প্রকাশ করতে চলেছে তখন আপনি এটি ব্যবহার করবেন পুরানো শ্রেণীর সমস্ত কার্যকারিতা ... তারপরে আপনি উত্তরাধিকারী হন।

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

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

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

ক্লাস ফক্স, স্পষ্টতই উড়তে পারে না। সুতরাং আপনি যদি সমস্ত বৈশিষ্ট্য থাকতে পূর্বপুরুষকে সংজ্ঞায়িত করেন তবে আপনি সঠিকভাবে বংশধরকে আবিষ্কার করতে পারবেন না।

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

যখন এটি সর্বোত্তম হয় তখন এই পদ্ধতির প্রতিটি ক্ষেত্রেই কেস ব্যবহার করা হয়, কোনও ক্ষেত্রেই সমস্ত ক্ষেত্রে নিখুঁত সেরা সমাধান হয় না।


1

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

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

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

পার্শ্ব নোট হিসাবে, আমি এটি দিয়ে কিছু সমস্যা নিয়েছি:

আমি সাধারণত একটি বেস ক্লাস তৈরি করি (বেশিরভাগ বিমূর্ত) এবং বিভিন্ন অন্যান্য অবজেক্টের সাথে একই কার্যকারিতা ভাগ করে নেওয়ার জন্য অবজেক্টের উত্তরাধিকার ব্যবহার করি।

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

আপনি যদি বলতে চান যে List<IWeapon>এটিতে বিভিন্ন ধরণের অস্ত্র থাকতে পারে তবে আপনি ইন্টারফেস ব্যবহার করতে পারেন । এইভাবে, আপনি IWeapon ইন্টারফেস এবং সমস্ত অস্ত্রের জন্য মনো-বিহ্যাভির সাবক্লাস উভয় থেকেই উত্তরাধিকারী হতে পারেন এবং একাধিক উত্তরাধিকারের অভাবে যে কোনও সমস্যা এড়াতে পারেন।


-3

আপনি একটি ইন্টারফেস কি বা বোঝে না বলে মনে হয়। আমাকে ওও সম্পর্কে প্রায় 10+ বছর চিন্তা করার এবং সত্যিকারের স্মার্ট লোকদের প্রশ্ন জিজ্ঞাসা করার ফলে আমি ইন্টারফেসের সাথে আহ-হা মুহুর্ত অর্জন করতে সক্ষম হয়েছি। আশাকরি এটা সাহায্য করবে.

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

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

একটি ইন্টারফেস হ'ল কেবলমাত্র আপনার ও ও কাঠামোটিকে অন্য ভিন্ন ওও কাঠামোর সাথে সম্পর্কিত করার জন্য প্রতিটি পক্ষের সাথে আলাদা আলাদা বৈশিষ্ট্যযুক্ত যেগুলি ভিন্ন ভিন্ন মাঝারি / পরিবেশে কিছু কার্যকরী আউটপুট উত্পাদন করার জন্য একে অপরের সাথে আলোচনার / মানচিত্রের আবশ্যক rela

মনকে ওপেন-হ্যান্ড ফাংশনটি কল করার জন্য এটি অবশ্যই নিজের ইন্টারফেসটি নার্ভ_কম্যান্ড_সিস্টেমটি বাস্তবায়িত করবে যাতে তার নিজস্ব এপিআই থাকতে হবে যাতে ওপেন-হ্যান্ডে কল করার আগে প্রয়োজনীয় সমস্ত প্রয়োজনীয়তা কীভাবে প্রয়োগ করা যায় সে সম্পর্কে নির্দেশাবলী রয়েছে।

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