বিজ্ঞপ্তি বর্গ নির্ভরতা

Question

একে অপরের প্রয়োজন এমন 2 টি ক্লাস রাখা কি খারাপ ডিজাইনের?

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

আপনি এই খারাপ নকশা কল করবেন? আমি কেবল জিজ্ঞাসা করছি, কারণ আমি যথেষ্ট নিশ্চিত নই এবং এই সময়ে আমি এখনও এই জিনিসগুলিকে সংশোধন করতে সক্ষম হয়েছি am

Comments

উত্তরটি হ্যাঁ হলে আমি খুব অবাক হব।

— doppelgreener

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

— teodron

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

— শেডডাব্লু 30'12

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

— ড্যাম্প এস 8 এন

Answer 1

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

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

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

এখনও অবধি আমরা জানি যে আউট ডিজাইনে আমাদের বিজ্ঞপ্তি নির্ভরতা প্রয়োজন। এটি নিরাপদে তৈরি করার একাধিক উপায় রয়েছে:

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

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

Answer 2

একে অপরের প্রয়োজন এমন 2 টি ক্লাস রাখা কি খারাপ ডিজাইনের?

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

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

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

আপনি কি আমার নকশাকে খারাপ ডিজাইন বলবেন?

না, সব কিছু এক শ্রেণিতে রাখার চেয়ে এটি আরও ভাল।

এটি এত দুর্দান্ত নয়, তবে এটি বেশিরভাগ বাস্তবায়নের কাছাকাছি যা আমি দেখেছি। সাধারণত, আপনার কাছে গেম স্টেটগুলির জন্য একটি ম্যানেজার ক্লাস ( সতর্ক থাকুন! ) এবং একটি রেন্ডারার ক্লাস থাকতে হবে এবং এটি সাধারণ যে তারা সিঙ্গেলন। সুতরাং বিজ্ঞপ্তি নির্ভরতা "লুকানো", তবে এটি সম্ভবত রয়েছে।

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

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

Comments

এটি একটি কোড গন্ধ হবে কেন? পিতা-মাতার সম্পর্কের সাথে বেশিরভাগ অবজেক্টের একে অপরকে দেখা দরকার।

— কিকাইমারু

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

— লরেন্ট কুইভিডউ

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

— কিকাইমারু

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

— লরেন্ট কুইভিডু

উইকিপিডিয়া নিবন্ধে সেই মামলার উল্লেখ নেই। আপনি যতক্ষণ না এই ক্লাসগুলি দেখেছেন ততক্ষণ আপনি এটি "অনুচিত ঘনিষ্ঠতা" এর একটি মামলা বলতে পারবেন না।

— কিকাইমারু

Answer 3

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

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

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

এর সমাধানের জন্য তিনটি পদ্ধতির মধ্যে রয়েছে:

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

Answer 4

কম দম্পতির সাথে উচ্চ সংহতি থাকা সাধারণত ভাল অনুশীলন বলে মনে হয়। সংযুক্তি এবং সংহতি সম্পর্কিত কয়েকটি লিঙ্ক এখানে।

উইকিপিডিয়া কাপলিং

উইকিপিডিয়া সংহতি

কম সংযোগ, উচ্চ সংহতি

সেরা অনুশীলন উপর স্ট্যাকওভারফ্লো

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