উত্তরাধিকার কখন বন্ধ করবেন?

Question

একবার আগে আমি উত্তরাধিকার সম্পর্কে স্ট্যাক ওভারফ্লোতে একটি প্রশ্ন জিজ্ঞাসা করেছি ।

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

public abstract class Piece
{
    public void MakeMove();
    public void TakeBackMove();
}

public abstract class Pawn: Piece {}

public class WhitePawn :Pawn {}

public class BlackPawn:Pawn {}

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

public abstract class Piece
{
    public Color Color { get; set; }
    public abstract void MakeMove();
    public abstract void TakeBackMove();
}

এইভাবে পিস তার রঙ জানতে পারে। প্রয়োগের পরে আমি দেখেছি আমার বাস্তবায়ন নীচের মত চলে।

public abstract class Pawn: Piece
{
    public override void MakeMove()
    {
        if (this.Color == Color.White)
        {

        }
        else
        {

        }
    }

    public override void TakeBackMove()
    {
        if (this.Color == Color.White)
        {

        }
        else
        {

        }
    }
}

এখন আমি দেখতে পাচ্ছি যে বাস্তবায়নের ক্ষেত্রে বিবৃতি যদি বর্ণের সম্পত্তি তৈরি করে। এটি অনুভব করে যে আমাদের উত্তরাধিকারক্রমক্রমের নির্দিষ্ট রঙের টুকরোগুলি দরকার।

এমন ক্ষেত্রে আপনার কি হোয়াইটপাউন, ব্ল্যাকপ্যাণের মতো ক্লাস রয়েছে বা আপনি কি রঙিন সম্পত্তি রেখে ডিজাইনে যেতে পারবেন?

এমন সমস্যা না দেখে আপনি কীভাবে ডিজাইন শুরু করতে চান? রঙ সম্পত্তি রাখুন বা উত্তরাধিকার সমাধান আছে?

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

আমি আসলেই জিজ্ঞাসা করছি যে রঙের সম্পত্তি ব্যবহারের কারণে উত্তরাধিকার ব্যবহারের পক্ষে বিবৃতি আরও ভাল হয়?

Comments

আপনি কেন একেবারে টুকরো মডেল করবেন তা আমি সত্যিই বুঝতে পারি না। আপনি যখন মেকমোভকে কল করবেন () এটি কোন পদক্ষেপটি তৈরি করবে? আমি বলব যে আপনি যা শুরু করতে চান তা বোর্ডের রাজ্যের মডেলিং করা এবং

— এটির

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

— জেমস অ্যান্ডারসন

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

— gnat

আরও চ্যালেঞ্জিং ইস্যু হ'ল প্রতিটি পিস টাইপের জন্য একটি সাব-ক্লাস তৈরি করা যায় কি না। পিস টাইপটি টুকরা রঙের চেয়ে আচরণগত দিকগুলি নির্ধারণ করে।

— NoChance

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

— ইভান প্লেস

Answer 1

আপনি কোনও অ্যাপ্লিকেশন ডিজাইন করুন যাতে যানবাহন থাকে gine আপনি কি এরকম কিছু তৈরি করেন?

class BlackVehicle : Vehicle { }
class DarkBlueVehicle : Vehicle { }
class DarkGreenVehicle : Vehicle { }
// hundreds of other classes...

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

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

অন্যদিকে, যদি আপনার কাছে থাকে WhitePawnএবং BlackPawn, খুব শীঘ্রই বা পরে আপনি লিখে ফেললে আমি অবাক হব না:

var piece = (Pawn)this.CurrentPiece;
if (piece is WhitePawn)
{
}
else // The pice is of type BlackPawn
{
}

এমনকি এমন কিছু:

public abstract class Pawn
{
    public Color Player
    {
        get
        {
            return this is WhitePawn ? Color.White : Color.Black;
        }
    }
}

// Now imagine doing the same thing for every other piece.

Comments

@ ফ্রেশব্লুড আমি মনে করি directionযে রঙ সম্পত্তি ব্যবহার করার চেয়ে কোনও সম্পত্তি থাকা এবং এটি স্থানান্তর করতে ব্যবহার করা ভাল। রঙটি কেবলমাত্র রেন্ডারিংয়ের জন্য ব্যবহার করা উচিত, যুক্তির জন্য নয়।

— জ্ঞান ওরফে গ্যারি বুইন

এছাড়াও, টুকরাগুলি একই দিকে এগিয়ে, পিছনে, বাম, ডানদিকে অগ্রসর হয়। পার্থক্য হ'ল বোর্ডের কোন দিক থেকে তারা শুরু করে। কোনও রাস্তায়, গলিগুলির বিপরীতে গাড়িগুলি উভয়ই এগিয়ে যায়।

— স্লিপসেট

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

— জ্ঞান ওরফে গ্যারি বুইন

আমি মনে করি আমরা দুটি ভিন্ন দৃষ্টিভঙ্গি থেকে একই জিনিসটির দিকে তাকাচ্ছি। দুই পক্ষ যদি লাল এবং নীল হয় তবে তাদের আচরণ কালো এবং সাদা হওয়ার সাথে কী আলাদা হবে? আমি না বলব, যে কারণেই আমি বলছি যে রঙ কোনও আচরণগত পার্থক্যের কারণ নয়। এটি কেবল একটি সূক্ষ্ম পার্থক্য তবে সে কারণেই আমি গেম যুক্তির পরিবর্তে একটি directionবা সম্ভবত একটি playerসম্পত্তি ব্যবহার করব would color

— জ্ঞান ওরফে গ্যারি বুইন

@ ফ্রেশব্লুড white castle's moves differ from black's- কিভাবে? আপনি কাস্টলিং মানে? কিং-সাইড কাস্টলিং এবং কুইন-সাইড কাস্টলিং উভয়ই কালো এবং হোয়াইটের জন্য 100% প্রতিসম।

— কনরাড মোরাউস্কি

Answer 2

আপনার নিজেকে যা জিজ্ঞাসা করা উচিত তা হ'ল আপনার বন্ধন শ্রেণিতে সত্যই কেন আপনার এই বিবৃতিগুলি দরকার:

    if (this.Color == Color.White)
    {

    }
    else
    {
    }

আমি যথেষ্ট নিশ্চিত যে এটির মতো ছোট ছোট ফাংশন রাখাই যথেষ্ট

public abstract class Piece
{
    bool DoesPieceHaveSameColor(Piece otherPiece) { /*...*/   }

    Color OtherColor{get{/*...*/}}
    // ...
}

আপনার পিস ক্লাসে এবং উপরের সমস্ত বিবৃতিগুলির কোনও ছাড়াই those ফাংশনগুলি ব্যবহার করে Pawn(এবং অন্যান্য ডেরিভেশনস Piece) সমস্ত ফাংশন ifবাস্তবায়ন করুন। শুধুমাত্র একটি ব্যতিক্রমই কোনও প্যাঁকে তার রঙের দ্বারা চলার দিক নির্ধারণের জন্য কার্যকারিতা হতে পারে, কারণ এটি प्यादेগুলির জন্য নির্দিষ্ট, তবে প্রায় অন্যান্য সমস্ত ক্ষেত্রে আপনার কোনও বর্ণ-নির্দিষ্ট কোডের প্রয়োজন হবে না।

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

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

Comments

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

— কনরাড মোরাওস্কি

Answer 3

উত্তরাধিকার হ'ল ততটা কার্যকর হয় না যখন এক্সটেনশনটি বস্তুর বাহ্যিক ক্ষমতাকে প্রভাবিত করে না ।

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

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

Comments

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

— কনরাড মোরাউস্কি

Answer 4

ব্যক্তিগতভাবে আমি কিছুতেই উত্তরাধিকার সূত্রে পাইনি Piece, কারণ আমি মনে করি না যে আপনি এটি করে কিছু লাভ করেছেন। সম্ভবত একটি টুকরা আসলে কীভাবে এটি স্থানান্তরিত করে তা যত্নশীল করে না , কেবলমাত্র পরবর্তী স্ক্রের জন্য কোন স্কোয়ারগুলি বৈধ গন্তব্য।

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

interface IMoveCalculator
{
    List<Square> GetValidDestinations();
}

class KnightMoveCalculator : IMoveCalculator;
class QueenMoveCalculator : IMoveCalculator;
class PawnMoveCalculator : IMoveCalculator; 
// etc.

class Piece
{
    IMoveCalculator move_calculator;
public:
    Piece(IMoveCalculator mc) : move_calculator(mc) {}
}

Comments

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

— স্টিভেন স্ট্রিগা

@ উইকএন্ডওয়ারিওর - "ব্যক্তিগতভাবে আমি কিছুতেই উত্তরাধিকার সূত্রে পাই না Piece"। এটি দেখে মনে হয় যে টুকরো কেবল চলাফেরা গণনা করার চেয়ে বেশি দায়বদ্ধ, এটি আলাদা উদ্বেগ হিসাবে আন্দোলন বিভক্ত করার কারণ। কোন টুকরোটি নির্ধারণ করে কোন ক্যালকুলেটর নির্ভরতা ইনজেকশন হিসাবে বিবেচিত হবে, যেমনvar my_knight = new Piece(new KnightMoveCalculator())

— বেন কট্রেল

এটি ফ্লাইওয়েট প্যাটার্নের জন্য ভাল প্রার্থী হবে। দাবাবোর্ডে 16 টি प्याদ রয়েছে এবং তারা সকলেই একই আচরণ করে । এই আচরণটি সহজেই একটি একক ফ্লাইওয়েটে বের করা যেতে পারে। অন্যান্য সমস্ত টুকরা একই হয়।

— ম্যাটড্যাভে

Answer 5

এই উত্তরে, আমি ধরে নিচ্ছি যে "দাবা ইঞ্জিন" দ্বারা, প্রশ্নের লেখক অর্থ "দাবা এআই", কেবল একটি চলন বৈধতা ইঞ্জিন নয়।

আমি মনে করি টুকরাগুলির জন্য OOP ব্যবহার করা এবং তাদের বৈধ আন্দোলন দুটি কারণে খারাপ ধারণা for

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

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

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

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

Comments

দাবা ইঞ্জিনটি খুব দ্রুত লেখার উদ্দেশ্য নয়।

— ফ্রেশব্লুড

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

— ডক ব্রাউন

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

— জো

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

— ডক ব্রাউন 16

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

— টিমোথি বাল্ড্রিজ