দাবা টুকরা জন্য উত্তরাধিকার বনাম রচনা


9

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

উত্তরাধিকার এই জাতীয় কিছু দেখতে হবে (যথাযথ নির্মাতা ইত্যাদি সহ)

class BasePiece
{
    virtual Squares GetValidMoveSquares() = 0;
    Mesh* mesh;
    // Other fields
}

class Pawn : public BasePiece
{
   Squares GetValidMoveSquares() override;
}

যা অবশ্যই "হ'ল একটি" নীতিকে মান্য করে যেখানে সংমিশ্রণটি এরকম কিছু দেখায়

class MovementComponent
{
    virtual Squares GetValidMoveSquares() = 0;
}

class PawnMovementComponent
{
     Squares GetValidMoveSquares() override;
}

enum class Type
{
     PAWN,
     BISHOP, //etc
}


class Piece
{
    MovementComponent* movementComponent;
    MeshComponent* mesh;
    Type type;
    // Other fields
 }

এটি কি ব্যক্তিগত পছন্দের বিষয় বা একটি পদ্ধতির স্পষ্টতই অন্যের তুলনায় একটি স্মার্ট পছন্দ?

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


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

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

গেমস প্রোগ্রামিংয়ে কৌশলগত কারণগুলি সাধারণ কারণ common var Pawn = new Piece(howIMove, howITake, whatILookLike)উত্তরাধিকারের শ্রেণিবদ্ধের চেয়ে আমার কাছে অনেক সহজ, আরও পরিচালনাযোগ্য এবং আরও রক্ষণাবেক্ষণযোগ্য বলে মনে হচ্ছে।
পিঁপিতে পি

@ এন্টপি এটি একটি ভাল পয়েন্ট, ধন্যবাদ!
ক্যানিস্লিপইট

@ উত্তর এটি উত্তর দিন! ... যে যথেষ্ট যোগ্যতা আছে!
এসভিডজেন

উত্তর:


4

প্রথম নজরে আপনার উত্তরটি "রচনা" সমাধান উত্তরাধিকার ব্যবহার করে না বলে ভান করে। তবে আমি অনুমান করি আপনি কেবল এটি যুক্ত করতে ভুলে গেছেন:

class PawnMovementComponent : MovementComponent
{
     Squares GetValidMoveSquares() override;
}

(এবং এগুলি থেকে প্রাপ্ত আরও অনেকগুলি ছয় প্রকারের প্রতিটিের জন্য একটি)। এখন এটিকে আরও ধ্রুপদী "কৌশল" প্যাটার্নের মতো দেখায় এবং এটি উত্তরাধিকারকেও কাজে লাগাচ্ছে।

দুর্ভাগ্যক্রমে, এই সমাধানটির একটি ত্রুটি রয়েছে: প্রত্যেকে Pieceএখন এটির টাইপ তথ্যকে রিলিজ করে রাখে দু'বার:

  • সদস্য ভেরিয়েবল ভিতরে type

  • ভিতরে movementComponent(উপ-টাইপ দ্বারা উপস্থাপিত)

এই অপ্রয়োজনীয়তা আপনাকে সত্যই সমস্যায় ফেলতে পারে - একটি সাধারণ শ্রেণীর মতো Pieceদুটি উত্স নয়, "সত্যের একক উত্স" সরবরাহ করা উচিত।

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

"উত্তরাধিকার" নকশায় নোট করুন, অপ্রয়োজনীয় উপায়ে "প্রকার" ক্ষেত্র সরবরাহ করা বেশ সহজ: একটি ভার্চুয়াল পদ্ধতি যুক্ত GetType()করুন BasePieceএবং প্রতিটি বেস শ্রেণিতে এটি অনুসারে প্রয়োগ করুন।

"পদোন্নতি" সম্পর্কিত: আমি @ এসভিডজেনের সাথে এখানে আছি, আমি @ থেটিক্সহিস্পেরারের উত্তরটি বিতর্কযোগ্য বলে উপস্থাপন করেছি ।

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


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

@ ক্যানিস্লাইপইট: আপনার প্রস্তাবিত "প্রকার" ক্ষেত্রের ক্ষেত্রে সমস্যাটি হ'ল, এটি সাব-টাইপ থেকে আলাদা হয়ে যেতে পারে movementComponent। "উত্তরাধিকার" ডিজাইনে নিরাপদ উপায়ে কোনও প্রকার ক্ষেত্র কীভাবে সরবরাহ করতে হয় তা আমার সম্পাদনা দেখুন।
ডক ব্রাউন

4

আপনার স্পষ্ট, সুনির্দিষ্ট কারণ বা দৃ ex় এক্সটেনসিবিলিটি এবং রক্ষণাবেক্ষণ সংক্রান্ত উদ্বেগ না থাকলে আমি সম্ভবত সহজ বিকল্পটি পছন্দ করব ।

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

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

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


আমি ক্রয় করি না যে উত্তরাধিকারের সমাধানটি 'কোডের কম লাইন'। সম্ভবত এই এক শ্রেণিতে কিন্তু সামগ্রিকভাবে নয়।
জিমি জেমস

@ জিমি জেমস সত্যিই? ... কেবল ওপিতে কোডের রেখাগুলি গণনা করুন ... স্বীকার করেছেন পুরো সমাধানটি নয়, তবে কোনও খারাপ সূচক নয় যার সমাধানটি আরও এলওসি এবং বজায় রাখতে জটিলতা is
এসভিডজেন

আমি এই বিষয়ে খুব একটা সূক্ষ্ম বিন্দু রাখতে চাই না কারণ এটি এই মুহুর্তে সমস্ত ধারণাগুলি তবে হ্যাঁ, আমি সত্যই তাই মনে করি। আমার যুক্তি এই যে এই বিট কোডটি পুরো অ্যাপ্লিকেশনটির তুলনায় नगणিক। এটি যদি নিয়মগুলির (বিতর্কযোগ্য) বাস্তবায়নকে সহজ করে তোলে তবে আপনি কয়েক ডজন বা এমনকি কয়েকশ লাইন কোড সংরক্ষণ করতে পারেন।
জিমি জেমস

ধন্যবাদ, আমি ইন্টারফেসটির কথা ভাবি নি তবে আপনি হয়ত ঠিক বলেছেন যে এটিই যাওয়ার সেরা উপায়। সহজ প্রায় সবসময় ভাল।
ক্যানিস্লিপইট

2

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

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

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


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

2

আমি সমস্যা ডোমেন (যেমন দাবারের বিধি) সম্পর্কে কিছু পর্যবেক্ষণ করে শুরু করব:

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

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

// pseudo-code, not pure C++

interface MovementRule {
  set<Square> getValidMoves(Board board, Square from); // what moves can I make from the given square?
  void makeMove(Board board, Square from, Square to); // update board state to reflect a specific move
}

class Game {
  Board board;
  map<PieceType, MovementRule> rules;
}

MovementRuleএকটি সাধারণ তবে নমনীয় ইন্টারফেস যা বাস্তবায়নগুলি কাস্টলিং এবং প্রচারের মতো জটিল পদক্ষেপগুলিকে সমর্থন করার জন্য প্রয়োজনীয় কোনওভাবে বোর্ডের স্টেট আপডেট করতে দেয় update স্ট্যান্ডার্ড দাবা এর জন্য, আপনার প্রতিটি প্রকারের টুকরোটির জন্য একটির প্রয়োগ রয়েছে তবে Gameদাবার বিভিন্ন রূপকে সমর্থন করার জন্য আপনি বিভিন্ন নিয়মে প্লাগ করতে পারেন ।


আকর্ষণীয় পদ্ধতির - চিন্তাভাবনার জন্য ভাল খাবার
CanISleepYet

1

আমি এই উদাহরণে ভাবেন যে উত্তরাধিকার পরিষ্কার পছন্দ হবে। রচনাটি আরও কিছুটা মার্জিত হতে পারে তবে এটি আমার কাছে আরও কিছুটা জোর করে বলে মনে হচ্ছে।

যদি আপনি অন্যান্য গেমগুলি বিকাশের পরিকল্পনা করে যা চলন্ত টুকরোগুলি পৃথকভাবে ব্যবহার করে, রচনাটি আরও ভাল পছন্দ হতে পারে, বিশেষত যদি আপনি প্রতিটি গেমের জন্য প্রয়োজনীয় টুকরোগুলি তৈরি করতে কোনও কারখানার প্যাটার্ন নিযুক্ত করেন।


2
উত্তরাধিকার ব্যবহার করে আপনি কীভাবে পদোন্নতি দিয়ে মোকাবেলা করবেন?
দ্যাটিক্যাটহিসার

4
আপনি যখন শারীরিকভাবে গেমটি খেলেন তখন আপনি কীভাবে এটি পরিচালনা করবেন ? (আশা করি আপনি এই টুকরোটি প্রতিস্থাপন করেছেন - আপনি
মহোদয়কে

0

যা অবশ্যই "হ'ল একটি" নীতি মেনে চলে

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



0

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

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

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

আমি একটি Pieceক্লাস এবং আপনার যেমন একটি ক্লাসকে সংজ্ঞায়িত করব PieceTypePieceTypeবর্গ সংজ্ঞায়িত যেমন, যেমন সব পদ্ধতি যা গুটি, রাণী, ect, সংজ্ঞায়িত করতে হবে, CanMoveTo, GetPieceTypeName, ect,। তারপরে Pawnএবং Queen, ect ক্লাসগুলি কার্যত ক্লাস থেকে উত্তরাধিকারী হবে PieceType


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

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

1
তাহলে Pieceভার্চুয়াল নয়, আমি এই সমাধান সঙ্গে একমত। বর্গ নকশা পৃষ্ঠের উপর কিছুটা জটিল মনে হতে পারে, আমি মনে করি বাস্তবায়ন সামগ্রিকভাবে সহজ হবে। প্রধান বিষয় আছে যা সঙ্গে যুক্ত করা হবে Pieceনা এবং PieceTypeএটা পরিচয় এবং সম্ভাব্য তার পদক্ষেপ ইতিহাস আছে।
জিমি জেমস

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

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

0

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

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

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

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

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

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


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

-1

ঠিক আছে, আমি উভয়েরই পরামর্শ দিচ্ছি না।

যদিও অবজেক্ট-ওরিয়েন্টেশন একটি দুর্দান্ত সরঞ্জাম এবং প্রায়শই জিনিসগুলিকে সরল করতে সহায়তা করে তবে এটি সরঞ্জামদণ্ডের একমাত্র সরঞ্জাম নয়।

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

খালি জন্য রিজার্ভ শূন্য, যদিও টুকরা জন্য 7 বিট রেখে মালিকের জন্য এমএসবি ব্যবহার করুন।
বিকল্পভাবে, খালি জন্য শূন্য, মালিকের জন্য স্বাক্ষর করুন, টুকরোটির জন্য নিখুঁত মান।

আপনি যদি চান তবে ম্যানুয়াল মাস্কিং এড়াতে আপনি বিটফিল্ডগুলি ব্যবহার করতে পারেন, যদিও সেগুলি অপ্রয়োগযোগ্য নয়:

class field {
    signed char data = 0;
public:
    constexpr field() = default;
    constexpr field(bool black, piece x) noexcept
    : data(x < piece::pawn || x > piece::king ? 0 : (black << 7) | x))
    {}
    constexpr bool is_black() noexcept { return data < 0; }
    constexpr bool is_white() noexcept { return data > 0; }
    constexpr bool empty() noexcept { return data == 0; }
    constexpr piece piece() noexcept { return piece(data & 0x7f); }
};

জবর ... এবং কার্যক্ষম বিবেচনায় এটি একটি সি ++ প্রশ্ন। তবে, সি ++ প্রোগ্রামার না হয়ে এটি আমার প্রথম (বা দ্বিতীয় বা তৃতীয় ) প্রবৃত্তি হবে না! ... যদিও এটি এখানে সর্বাধিক সি ++ উত্তর হতে পারে !
এসভিডজেন

7
এটি এমন একটি মাইক্রোপটিমাইজেশন যা কোনও বাস্তব প্রয়োগ অনুসরণ করা উচিত নয়।
মিথ্যা রায়ান

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

হেহ ... যে বলেন , সি ++ হয় অবজেক্ট ওরিয়েন্টেড। আমি ধরে নিই যে এর কোনও কারণ নেই যে ওপি কেবলমাত্র সি এর পরিবর্তে সি ++ ব্যবহার করছে ।
এসভিডজেন

3
এখানে আমি ওওপির অভাব সম্পর্কে কম চিন্তিত, বরং বিট টুইডলিংয়ের সাথে কোডটি অবলম্বন করছি। আপনি যদি 8-বিট নিন্টেন্ডোর জন্য কোড লিখছেন না বা আপনি অ্যালগরিদমগুলি লিখছেন যা বোর্ডের রাজ্যের কয়েক মিলিয়ন অনুলিপিগুলির সাথে ডিলের প্রয়োজন, এটি অকাল মাইক্রোপটিমাইজেশন এবং অনিবার্য। সাধারণ পরিস্থিতিতে, এটি সম্ভবত দ্রুততর হবে না কারণ স্বাক্ষরযুক্ত বিট অ্যাক্সেসের জন্য অতিরিক্ত বিট-অপারেশন প্রয়োজন requires
মিথ্যা রায়ান
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.