এই বাস্তব-বিশ্বের ক্রিয়াকলাপকে মডেল করার উপযুক্ত উপায়টি কী বলে মনে হয় যে ওওপিতে বিজ্ঞপ্তি রেফারেন্সের দরকার পড়ে?


24

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

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

ক্লাসগুলি হ'ল:

  • রুলবুক: এমন একটি বিষয় যা বোর্ডের প্রাথমিক লেআউট, অন্যান্য প্রাথমিক গেমের রাজ্য সম্পর্কিত তথ্য যেমন কে প্রথমে চলে যায়, যে চালগুলি পাওয়া যায়, প্রস্তাবিত পদক্ষেপের পরে গেম স্টেটের কী হয় এবং এর মূল্যায়ন যেমন বিষয়গুলির জন্য জিজ্ঞাসাবাদ করা যেতে পারে object একটি বর্তমান বা প্রস্তাবিত বোর্ড অবস্থান।

  • বোর্ড: একটি গেম বোর্ডের একটি সরল উপস্থাপনা, যা মুভ প্রতিফলিত করার নির্দেশ দেওয়া যেতে পারে।

  • মুভলিস্ট: মুভসের একটি তালিকা। এটি দ্বৈত-উদ্দেশ্য: একটি নির্দিষ্ট পয়েন্টে চলনগুলির একটি পছন্দ বা গেমটিতে তৈরি হওয়া চালগুলির তালিকা। এটি দুটি কাছাকাছি-অভিন্ন শ্রেণিতে বিভক্ত হতে পারে, তবে এটি যে প্রশ্নটি আমি জিজ্ঞাসা করছি তার সাথে প্রাসঙ্গিক নয় এবং এটি আরও জটিল করে তুলতে পারে।

  • সরান: একক চাল। এটিতে পরমাণুর তালিকা হিসাবে সরানো সম্পর্কে সমস্ত কিছু অন্তর্ভুক্ত রয়েছে: এখান থেকে একটি টুকরো তুলে এটিকে এখানে রাখুন, সেখান থেকে একটি বন্দী টুকরোটি সরিয়ে ফেলুন।

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

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

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

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

আপনার যে কোন সাহায্যের জন্য ধন্যবাদ!


7
কী যদি RuleBookউদাহরণস্বরূপ Stateএকটি আর্গুমেন্ট হিসাবে গ্রহণ করে এবং বৈধটি ফেরত দেয় MoveList, অর্থাৎ "আমরা এখন যেখানে আছি, এর পরে কী করা যায়?"
jonrsharpe

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

4
Objectশ্বর অবজেক্ট (বিগক্লাসট্যাটডোসএলমাস্টওয়ারিথিংথিংইনজেম) এড়ানো বৃত্তাকার উল্লেখগুলি এড়িয়ে যাওয়ার চেয়ে অনেক বেশি গুরুত্বপূর্ণ।
ব্যবহারকারী 281377

2
@ ব্যবহারকারী ২13১ they7777 এগুলি অবশ্য পারস্পরিক একচেটিয়া উদ্দেশ্য নয়, যদিও!
জোনারশপে

1
আপনি কি মডেলিংয়ের চেষ্টাগুলি দেখাতে পারেন? উদাহরণস্বরূপ একটি চিত্র?
ব্যবহারকারী

উত্তর:


47

বিজ্ঞপ্তি রেফারেন্স সম্পর্কে আমি একটি জাভা প্রকল্পে একটি সমস্যা নিয়ে কুস্তি করছি।

জাভার আবর্জনা সংগ্রহকারী রেফারেন্স গণনা কৌশলগুলিতে নির্ভর করে না। বিজ্ঞপ্তি রেফারেন্স জাভাতে কোনও ধরণের সমস্যা সৃষ্টি করে না। জাভাতে পুরোপুরি প্রাকৃতিক বিজ্ঞপ্তি রেফারেন্সগুলি দূর করতে ব্যয় করা সময় নষ্ট হয়।

আমি এটিকে কোড করেছিলাম [...] তবে সমস্যাটি হ'ল এটি বিজ্ঞপ্তিযুক্ত রেফারেন্সে পূর্ণ। আমি তখন একে একে একটি উত্স ফাইলে অন্তর্নির্মিত ক্লাসগুলি ভর্তি করে তা প্রয়োগ করেছিলাম , [...]

জরুরী না. আপনি যদি একবারে সমস্ত উত্স ফাইলগুলি একবারে সংকলন করেন (যেমন, javac *.java), সংকলক সমস্যা ছাড়াই সমস্ত ফরোয়ার্ড রেফারেন্স সমাধান করবে।

বা আমি পারস্পরিক নির্ভরশীল ক্লাসগুলির সাথে লেগে থাকতে পারি এবং সংকলকটি কোনওভাবে তাদের সংকলন করার জন্য কোক্স করব, [...]

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


24
"বিজ্ঞপ্তি রেফারেন্স জাভাতে কোনও ধরণের সমস্যা সৃষ্টি করে না।" সংকলনের ক্ষেত্রে এটি সত্য this যদিও বিজ্ঞপ্তি রেফারেন্সগুলি খারাপ ডিজাইন হিসাবে বিবেচিত হয়
চপ

22
বিজ্ঞপ্তি উল্লেখ অনেক পরিস্থিতিতে একেবারে প্রাকৃতিক, এজন্য জাভা এবং অন্যান্য আধুনিক ভাষাগুলি একটি সাধারণ রেফারেন্স কাউন্টারের পরিবর্তে একটি পরিশীলিত আবর্জনা সংগ্রহকারী ব্যবহার করে।
ব্যবহারকারী 281377

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

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

2
এই উত্তরটি কেবল মধ্যযুগীয়, কারণ ওপির উদাহরণ হিসাবে কার্যকর বিজ্ঞপ্তি সংক্রান্ত বিজ্ঞপ্তি সংক্রান্ত একটি শব্দ নেই useful
ডক ব্রাউন

22

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

প্রকৃতপক্ষে, খুব কম দৃশ্যপট রয়েছে যেখানে জাভা সংকলক একটি বিজ্ঞপ্তি নির্ভরতা অস্বীকার করবে। (দ্রষ্টব্য: আরও কিছু থাকতে পারে, আমি এখনই নিম্নলিখিতগুলি সম্পর্কে কেবল ভাবতে পারি))

  1. উত্তরাধিকারে: আপনার ক্লাস 'এ' বর্ধমান শ্রেণি বি থাকতে পারে না যা ঘড়িতে ক্লাস 'এ'কে প্রসারিত করে, এবং এটি পুরোপুরি যুক্তিসঙ্গত যে আপনার এটি থাকতে পারে না, কারণ বিকল্পটি যৌক্তিক দৃষ্টিকোণ থেকে একেবারেই কোনও ধারণা দেবে না।

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

সুতরাং, এটি অনুধাবন করা এবং এটি যেভাবে বিজ্ঞপ্তি নির্ভরতা হ্রাস করার চেষ্টা নকশা বিশুদ্ধতার জন্য অনুসন্ধান, প্রযুক্তিগত নির্ভুলতার জন্য অনুসন্ধান নয় তা থেকে বেরিয়ে আসা গুরুত্বপূর্ণ।

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

আপনার যে বিশেষ পরিস্থিতিতে আপনার হাত রয়েছে, এটি আমার কাছে মনে হয়েছে যে আপনার যা প্রয়োজন তা হ'ল একটি নতুন সত্তা, সম্ভবত "গেম" বা "গেমলজিক" নামে পরিচিত, যা অন্যান্য সমস্ত সত্তা জানেন, (অন্য কোনও সত্তা এটি না জেনেই, ) যাতে অন্য সত্তাগুলি একে অপরকে জানতে না পারে।

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

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


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

10

গেম থিওরি গেমগুলিকে পূর্ববর্তী চালগুলির তালিকা হিসাবে গণ্য করে (তাদের ধরণের খেলাগুলি সহ মানের ধরণ) এবং একটি ফাংশন ভ্যালিডমোভস (পূর্ববর্তী মওস)

আমি গেমের ইউআইআই অংশবিহীন অংশের জন্য এই প্যাটার্নটি চেষ্টা করে অনুসরণ করব এবং বোর্ড সেটআপের মতো জিনিসগুলি চাল হিসাবে বিবেচনা করব।

ইউআই তখন যুক্তির সাথে একপেশে রেফারেন্স সহ স্ট্যান্ডার্ড ওও স্টাফ হতে পারে


মন্তব্যগুলি ঘনীভূত করতে আপডেট করুন

দাবা বিবেচনা করুন। দাবা গেমগুলি সাধারণত চালগুলির তালিকা হিসাবে রেকর্ড করা হয়। http://en.wikipedia.org/wiki/Portable_Game_Notation

পদক্ষেপের তালিকা বোর্ডের চিত্রের চেয়ে গেমের সম্পূর্ণ অবস্থাকে আরও ভালভাবে সংজ্ঞায়িত করে।

উদাহরণস্বরূপ বলুন আমরা বোর্ড, পিস, মুভ ইত্যাদি এবং পিসের মতো পদ্ধতিগুলির জন্য বস্তু তৈরি শুরু করি et

প্রথমে আমরা দেখতে পাই বোর্ডে টুকরো টুকরো রেফারেন্স রাখতে হবে তবে আমরা কাস্টিং বিবেচনা করি consider যা আপনি কেবল তখনই করতে পারেন যদি আপনি ইতিমধ্যে আপনার রাজা বা নাড়াচাড়া না করে থাকেন। সুতরাং আমাদের রাজা এবং কান্ডের উপর একটি মুভলড্রিডি পতাকা দরকার। তেমনিভাবে পদ্মরা তাদের প্রথম পদক্ষেপে 2 স্কোয়ার স্থানান্তর করতে পারে।

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

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

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

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

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


এটি ValidMoves এর বাস্তবায়নকে জটিল করে তুলবে, যা আপনার যুক্তিটিকে ধীর করে দেবে।
তাইমির

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

1
পতাকা ও স্টাফ যুক্ত করা কেবলমাত্র সরানোর ইতিহাস থাকার দ্বারা আপনি এড়ানো জটিলতা complex বর্তমান বোর্ড সেটআপ পেতে 100 দাবা চাল সম্পর্কে বলা লুপ করা ব্যয়বহুল নয় এবং আপনি চালগুলির মধ্যে ফলাফলটি ক্যাশে করতে পারবেন
ইওয়ান

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

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

8

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


6

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

আমি মনে করি আপনার কাছে এমন একটি নিয়ামক ("যদি আপনি চান তবে" একটি গেম মাস্টার) থাকা উচিত যা গেমের প্রবাহকে নিয়ন্ত্রণ করে এবং নিয়ম বই বা গেম রাষ্ট্রকে এই দায়িত্ব দেওয়ার পরিবর্তে প্রকৃত অবস্থার পরিবর্তনগুলি পরিচালনা করে।

একটি গেম স্টেট অবজেক্টের নিজেকে পরিবর্তন করা বা নিয়ম সম্পর্কে সচেতন হওয়ার দরকার নেই। ক্লাসে কেবল সহজেই পরিচালনা করা (তৈরি, পরিদর্শন, পরিবর্তিত, অব্যাহত, লগ করা, অনুলিপি করা, কশেড ইত্যাদি) এবং অ্যাপ্লিকেশনটির বাকি অংশগুলির জন্য দক্ষ গেম স্টেট অবজেক্টের একটি মডেল সরবরাহ করতে হবে।

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

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


4
ঠিক আমার চিন্তাভাবনা। ওপি একই ক্লাসে খুব বেশি ডেটা এবং পদ্ধতি মিশ্রিত করছে । এগুলি আরও বিভক্ত করা ভাল। বিষয়টিতে এটি একটি ভাল কথা। বিটিডব্লিউ, আমি যখন "গেমের অবস্থার প্রতি দৃষ্টিভঙ্গি" পড়ি তখন আমার মনে হয় "ফাংশনটির পক্ষে যুক্তি"। আমি পারলে +100।
jpmc26

5

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

আসুন প্রতিটি ক্লাস কী করে তা বর্ণনা দিয়ে শুরু করি।

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

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

এখন RuleBookনিয়ম সম্পর্কে সমস্ত কিছু জানার জন্য ক্লাস দায়বদ্ধ। এটি তিনটি জিনিস ভেঙে দেওয়া যেতে পারে। প্রাথমিকটি GameStateকী তা জানা দরকার, কী পদক্ষেপ বৈধ হয় তা জানতে হবে এবং খেলোয়াড়দের মধ্যে কেউ জিতেছে কিনা তা জানাতে সক্ষম হওয়া প্রয়োজন।

আপনি GameHistoryতৈরি করা সমস্ত চাল এবং GameStatesযা ঘটেছিল তার সমস্ত নজর রাখার জন্য একটি শ্রেণি তৈরি করতে পারেন। একটি নতুন শ্রেণি আবশ্যক কারণ আমরা স্থির করেছিলাম যে এর আগে যে GameStateসবকটি GameStateঘটেছিল সেগুলি জানার জন্য একটি অবিবাহিতকে দায়বদ্ধ করা উচিত নয় ।

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

প্রথমটি GameState। যেহেতু এই শ্রেণিটি সম্পূর্ণ গেমের উপর সম্পূর্ণ নির্ভরশীল, তাই জেনেরিক Gamestateইন্টারফেস বা শ্রেণি নেই।

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

package boardgame;

/**
 *
 * @param <T> The type of GameState
 */
public interface Move<T> {

    T makeResultingState(T preMoveState) throws IllegalArgumentException;

}

লক্ষ্য করুন যে এখানে একটি টাইপ প্যারামিটার রয়েছে। এটি কারণ, উদাহরণস্বরূপ, ChessMoveইচ্ছার প্রাক-পদক্ষেপের বিশদগুলি সম্পর্কে জানতে হবে ChessGameState। সুতরাং, উদাহরণস্বরূপ, শ্রেণীর ঘোষণা ChessMoveহবে would

class ChessMove extends Move<ChessGameState>,

আপনি ইতিমধ্যে একটি ChessGameStateক্লাস সংজ্ঞায়িত করা হবে যেখানে ।

এরপরে আমি জেনেরিক RuleBookক্লাস নিয়ে আলোচনা করব । কোডটি এখানে:

package boardgame;

import java.util.List;

/**
 *
 * @param <T> The type of GameState
 */
public interface RuleBook<T> {

    T makeInitialState();

    List<Move<T>> makeMoveList(T gameState);

    StateEvaluation evaluateState(T gameState);

    boolean isMoveLegal(Move<T> move, T currentState);

}

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

package boardgame;

/**
 *
 */
public enum StateEvaluation {

    UNFINISHED,
    PLAYER_ONE_WINS,
    PLAYER_TWO_WINS,
    DRAW,
    ILLEGAL_STATE
}

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

package boardgame;

import java.util.ArrayList;
import java.util.List;

/**
 *
 * @param <T> The type of GameState
 */
public class GameHistory<T> {

    private List<T> states;
    private List<Move<T>> moves;

    public GameHistory(T initialState) {
        states = new ArrayList<>();
        states.add(initialState);
        moves = new ArrayList<>();
    }

    void recordMove(Move<T> move) throws IllegalArgumentException {
        moves.add(move);
        states.add(move.makeResultingState(getMostRecentState()));
    }

    void resetToNthState(int n) {
        states = states.subList(0, n + 1);
        moves = moves.subList(0, n);
    }

    void undoLastMove() {
        resetToNthState(getNumberOfMoves() - 1);
    }

    T getMostRecentState() {
        return states.get(getNumberOfMoves());
    }

    T getStateAfterNthMove(int n) {
        return states.get(n + 1);
    }

    Move<T> getNthMove(int n) {
        return moves.get(n);
    }

    int getNumberOfMoves() {
        return moves.size();
    }

}

অবশেষে, আমরা Gameসবকিছুকে এক সাথে বেঁধে রাখার জন্য ক্লাস তৈরি করার কল্পনা করতে পারি । এই Gameশ্রেণীর এমন পদ্ধতি উদ্ঘাটিত করার কথা রয়েছে যা মানুষের পক্ষে কারেন্টটি কী তা দেখতে সক্ষম করে GameState, কার কার কাছে যদি থাকে তবে কী চলাচল করা যায় তা দেখুন এবং একটি চালচলন খেলবেন তা দেখুন। আমি নীচে একটি বাস্তবায়ন আছে

package boardgame;

import java.util.List;

/**
 *
 * @author brian
 * @param <T> The type of GameState
 */
public class Game<T> {

    GameHistory<T> gameHistory;
    RuleBook<T> ruleBook;

    public Game(RuleBook<T> ruleBook) {
        this.ruleBook = ruleBook;
        final T initialState = ruleBook.makeInitialState();
        gameHistory = new GameHistory<>(initialState);
    }

    T getCurrentState() {
        return gameHistory.getMostRecentState();
    }

    List<Move<T>> getLegalMoves() {
        return ruleBook.makeMoveList(getCurrentState());
    }

    void doMove(Move<T> move) throws IllegalArgumentException {
        if (!ruleBook.isMoveLegal(move, getCurrentState())) {
            throw new IllegalArgumentException("Move is not legal in this position");
        }
        gameHistory.recordMove(move);
    }

    void undoMove() {
        gameHistory.undoLastMove();
    }

    StateEvaluation evaluateState() {
        return ruleBook.evaluateState(getCurrentState());
    }

}

এই শ্রেণিতে লক্ষ্য করুন যে RuleBookবর্তমানটি কী তা জানার জন্য দায়বদ্ধ নয় GameState। এটাই GameHistoryকাজ। সুতরাং Gameপ্রশ্নগুলি GameHistoryবর্তমান রাষ্ট্রটি কী তা জিজ্ঞাসা করে এবং আইনী পদক্ষেপগুলি কী তা বা কেউ জিতেছে কিনা তা RuleBookযখন Gameবলার দরকার পড়ে তখন এই তথ্যটি দেয় ।

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


3

আমার অভিজ্ঞতায়, বিজ্ঞপ্তি সংক্রান্ত রেফারেন্সগুলি সাধারণত নির্দেশ করে যে আপনার নকশাটি সুচিন্তিত নয়।

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


+1 টি। আপনি একটি শারীরিক বোর্ড গেম কিনেছেন, আপনি একটি নিয়ম বই পাবেন যা রাষ্ট্র ছাড়াই বিধিগুলি বর্ণনা করতে সক্ষম।
unPress325680

1

বিজ্ঞপ্তি নির্ভরতা অগত্যা কোনও প্রযুক্তিগত সমস্যা নয়, তবে এটি একটি কোড গন্ধ হিসাবে বিবেচনা করা উচিত, এটি সাধারণত একক দায়িত্বের নীতি লঙ্ঘন ।

আপনার বিজ্ঞপ্তি নির্ভরতা এই বিষয়টি থেকে আসে যে আপনি নিজের Stateঅবজেক্ট থেকে খুব বেশি চেষ্টা করার চেষ্টা করছেন ।

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

এই ক্ষেত্রে, আপনি একটি থাকার চেয়ে ভাল হবেন StateFactory, যা এ সম্পর্কে জানতে পারে Rulebook। আপনার কাছে সম্ভবত অন্য একটি নিয়ামক শ্রেণি রয়েছে যা StateFactoryএকটি নতুন গেম তৈরি করতে আপনার ব্যবহার করে । Stateঅবশ্যই সম্পর্কে জানা উচিত নয় Rulebook। আপনার বিধি বাস্তবায়নের উপর নির্ভর করে Rulebookসম্পর্কে জানতে পারে State


0

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

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

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


-2

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


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