शतरंज के मोहरों के लिए विरासत बनाम रचना

9

इस स्टैकएक्सचेंज की एक त्वरित खोज से पता चलता है कि सामान्य रचना में आमतौर पर विरासत की तुलना में अधिक लचीला माना जाता है लेकिन हमेशा की तरह यह परियोजना आदि पर निर्भर करता है और ऐसे समय होते हैं जब विरासत बेहतर विकल्प होता है। मैं एक 3 डी शतरंज खेल बनाना चाहता हूं, जहां प्रत्येक टुकड़े में एक जाल है, संभवतः विभिन्न एनिमेशन और इतने पर। इस ठोस उदाहरण में ऐसा लगता है जैसे आप दोनों दृष्टिकोणों के लिए एक मामला बहस कर सकते हैं क्या मैं गलत हूं?

वंशानुक्रम कुछ इस तरह दिखेगा (उचित निर्माणकर्ता आदि के साथ)

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

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

जो निश्चित रूप से "is-a" सिद्धांत का पालन करता है जबकि रचना कुछ इस तरह दिखती है

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
 }

क्या यह अधिक व्यक्तिगत पसंद की बात है या एक दृष्टिकोण स्पष्ट रूप से अन्य की तुलना में एक स्मार्ट विकल्प है?

संपादित करें: मुझे लगता है कि मैंने हर उत्तर से कुछ सीखा है इसलिए मुझे केवल एक चुनने के लिए बुरा लगता है। मेरा अंतिम समाधान यहां के कई पदों से प्रेरणा लेगा (अभी भी इस पर काम कर रहा है)। सभी को धन्यवाद जिन्होंने जवाब देने के लिए समय लिया।

c++ inheritance composition

— CanISleepYet
स्रोत

मेरा मानना है कि दोनों अलग-अलग हो सकते हैं, ये दोनों अलग-अलग उद्देश्य के लिए हैं, लेकिन ये एक-दूसरे के लिए अनन्य नहीं हैं। शतरंज अलग-अलग टुकड़ों और बोर्डों से बना है, और टुकड़े अलग-अलग प्रकार के हैं। ये टुकड़े कुछ बुनियादी संपत्ति और व्यवहार को साझा करते हैं, और विशिष्ट संपत्ति और व्यवहार भी होते हैं। तो मेरे अनुसार, रचना को बोर्ड और टुकड़ों पर लागू किया जाना चाहिए, जबकि विरासत को टुकड़ों के प्रकार पर पालन किया जाना चाहिए।

— हितेश गौर

जब आप कुछ लोगों को यह दावा कर सकते हैं कि सभी उत्तराधिकार खराब हैं, तो मुझे लगता है कि सामान्य विचार यह है कि इंटरफ़ेस वंशानुक्रम अच्छा / ठीक है और कार्यान्वयन कार्यान्वयन उपयोगी है, लेकिन समस्याग्रस्त हो सकता है। विरासत के एक भी स्तर से परे कुछ भी संदिग्ध है, मेरे अनुभव में। यह उससे परे ठीक हो सकता है लेकिन एक जटिल गड़बड़ किए बिना इसे खींचना सरल नहीं है।

— जिमीजैम

रणनीति प्रोग्रामिंग एक कारण के लिए खेल प्रोग्रामिंग में आम है। var Pawn = new Piece(howIMove, howITake, whatILookLike)एक विरासत पदानुक्रम की तुलना में मेरे लिए बहुत सरल, अधिक प्रबंधनीय और अधिक रखरखाव योग्य लगता है।

— एंट पी

@AntP यह एक अच्छी बात है, धन्यवाद!

— CanISleepYet

@AntP इसे उत्तर दें! ... वहाँ बहुत योग्यता है!

— svidgen

4

पहली नज़र में, आपका जवाब "संरचना" समाधान का दिखावा करता है जो विरासत का उपयोग नहीं करता है। लेकिन मुझे लगता है कि आप इसे जोड़ना भूल गए:

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

(और इन व्युत्पत्तियों में से प्रत्येक, छह टुकड़े प्रकारों में से एक के लिए)। अब यह शास्त्रीय "रणनीति" पैटर्न की तरह दिखता है, और यह विरासत का उपयोग भी कर रहा है।

दुर्भाग्य से, इस समाधान में एक दोष है: प्रत्येक Pieceअब इसे दो बार अनावश्यक रूप से टाइप की गई जानकारी रखता है:

सदस्य चर के अंदर type
अंदर movementComponent(उपप्रकार द्वारा पुन: प्रकाशित)

यह अतिरेक वह है जो आपको वास्तव में परेशानी में डाल सकता है - एक साधारण वर्ग Pieceको एक "सत्य का एकल स्रोत" प्रदान करना चाहिए, न कि दो स्रोत।

बेशक, आप केवल प्रकार की जानकारी संग्रहीत करने का प्रयास कर सकते हैं typeऔर MovementComponentसाथ ही साथ कोई भी बाल वर्ग नहीं बना सकते हैं । लेकिन इस डिजाइन switch(type)के कार्यान्वयन में संभवतः एक विशाल " " बयान होगा GetValidMoveSquares। और यह निश्चित रूप से विरासत के लिए एक मजबूत संकेत है कि यहां बेहतर विकल्प है ।

"विरासत" डिजाइन में ध्यान दें, यह काफी आसान एक गैर-अनावश्यक रास्ते में "प्रकार" क्षेत्र प्रदान करना है: एक आभासी विधि जोड़ने के GetType()लिए BasePieceऔर प्रत्येक आधार वर्ग में तदनुसार इसे लागू।

"पदोन्नति" के बारे में: मैं यहाँ @svidgen के साथ हूँ, मुझे @ TheCatWhisperer के उत्तर पर बहस करने योग्य तर्क प्रस्तुत किए गए हैं ।

"प्रमोशन" को टुकड़ों के भौतिक विनिमय के रूप में व्याख्या करने के बजाय इसे उसी प्रकार के परिवर्तन के रूप में व्याख्या करना मेरे लिए काफी अधिक स्वाभाविक लगता है। इसलिए इसे एक समान तरीके से लागू करना - एक टुकड़े को दूसरे प्रकार से आदान-प्रदान करने से - शायद सबसे बड़ी समस्या नहीं होगी - कम से कम शतरंज के विशिष्ट मामले के लिए नहीं।

— डॉक्टर ब्राउन
स्रोत

मुझे पैटर्न का नाम बताने के लिए धन्यवाद, मुझे यह महसूस नहीं हुआ कि इसे रणनीति कहा जाता है। तुम भी सही हो मैं अपने प्रश्न में आंदोलन घटक की विरासत को याद किया। क्या वास्तव में प्रकार निरर्थक है? अगर मैं बोर्ड पर सभी रानियों को रोशन करना चाहता हूं, तो यह जांचना अजीब होगा कि उनके पास कौन सा आंदोलन घटक है, साथ ही मुझे आंदोलन घटक को यह देखने की आवश्यकता होगी कि यह किस प्रकार का है जो सुपर बदसूरत नहीं होगा?

— CanISleepYet

@CanISleepYet: आपके प्रस्तावित "प्रकार" फ़ील्ड के साथ समस्या यह है, यह उप-प्रकार से अलग हो सकता है movementComponent। "विरासत" डिजाइन में सुरक्षित तरीके से एक प्रकार का क्षेत्र प्रदान करने के लिए मेरा संपादन देखें।

— डॉक ब्राउन

4

जब तक आपके पास स्पष्ट, सुव्यवस्थित कारण या मजबूत एक्स्टेंसिबिलिटी और रखरखाव संबंधी चिंताएं न हों, तब तक मैं सरल विकल्प को पसंद करूंगा ।

वंशानुक्रम विकल्प कोड की कम लाइन और कम जटिलता है। प्रत्येक प्रकार के टुकड़े का अपनी आंदोलन विशेषताओं के साथ "अपरिवर्तनीय" 1-टू -1 संबंध है। (इसके विपरीत यह प्रतिनिधित्व है, जो 1 से 1 है, लेकिन जरूरी नहीं कि अपरिवर्तनीय है - आप विभिन्न "खाल" की पेशकश करना चाह सकते हैं।)

यदि आप टुकड़ों और उनके व्यवहार / आंदोलन के बीच इस अपरिवर्तनीय 1-टू -1 संबंध को कई वर्गों में तोड़ते हैं, तो आप शायद केवल जटिलता जोड़ रहे हैं - और बहुत कुछ नहीं। इसलिए, अगर मैं उस कोड की समीक्षा कर रहा हूं या उसे विरासत में दे रहा हूं, तो मुझे जटिलता के लिए अच्छे, प्रलेखित कारणों को देखने की उम्मीद होगी।

सभी ने कहा, एक और भी सरल विकल्प , आईएमओ, एक Piece इंटरफ़ेस बनाना है जिसे आपके व्यक्तिगत टुकड़े कार्यान्वित करते हैं । अधिकांश भाषाओं में, यह वास्तव में विरासत से बहुत अलग है , क्योंकि एक इंटरफ़ेस आपको दूसरे इंटरफ़ेस को लागू करने से प्रतिबंधित नहीं करेगा । ... आपको उस मामले में मुफ्त में कोई आधार वर्ग व्यवहार नहीं मिलता है: आप साझा व्यवहार को कहीं और रखना चाहते हैं।

— svidgen
स्रोत

मैं नहीं खरीदता कि विरासत समाधान 'कोड की कम लाइनें' है। शायद इस एक वर्ग में लेकिन समग्र रूप से नहीं।

— जिमीजैम

@JimmyJames सच में? ... बस ओपी में कोड की पंक्तियों को गिनें ... वास्तव में संपूर्ण समाधान नहीं है, लेकिन एक बुरा संकेतक नहीं है कि किस समाधान को बनाए रखने के लिए अधिक एलओसी और जटिलता है।

— svidgen

मैं इस पर एक बिंदु भी ठीक नहीं करना चाहता क्योंकि यह इस बिंदु पर सभी उल्लेखनीय है, लेकिन हाँ, मुझे वास्तव में ऐसा लगता है। मेरा तर्क यह है कि पूरे आवेदन की तुलना में कोड का यह बिट नगण्य है। यदि यह नियमों (डिबेटेबल) के कार्यान्वयन को सरल करता है, तो आप दर्जनों या सैकड़ों लाइनों की कोड को बचा सकते हैं।

— जिमीजैम

धन्यवाद, मैंने इंटरफ़ेस के बारे में नहीं सोचा था लेकिन आप अच्छी तरह से सही हो सकते हैं कि यह जाने का सबसे अच्छा तरीका है। सरल हमेशा लगभग बेहतर होता है।

— CanISleepYet

2

शतरंज के साथ बात यह है कि खेल खेलते हैं और टुकड़ा नियम निर्धारित और निर्धारित किया जाता है। कोई भी डिज़ाइन जो काम करता है वह ठीक है - जो भी आपको पसंद है उसका उपयोग करें! प्रयोग करो और उन सब को आज़माओ।

व्यापार की दुनिया में, हालांकि, इस तरह से कुछ भी सख्ती से निर्धारित नहीं है - समय के साथ व्यापार के नियम और आवश्यकताएं बदल जाती हैं, और कार्यक्रमों को समायोजित करने के लिए समय के साथ बदलना पड़ता है। यह वह जगह है जहां एक बनाम एक है-एक बनाम डेटा से फर्क पड़ता है। यहां, सादगी समय के साथ और बदलती आवश्यकताओं को बनाए रखने के लिए जटिल समाधानों को आसान बनाती है। सामान्य तौर पर, व्यापार में, हमें दृढ़ता से भी निपटना पड़ता है, जिसमें एक डेटाबेस भी शामिल हो सकता है। इसलिए, हमारे पास ऐसे नियम हैं जैसे कि एकल वर्ग नौकरी करते समय कई वर्गों का उपयोग नहीं करता है और, जब रचना पर्याप्त होती है तो वंशानुक्रम का उपयोग नहीं करते हैं। लेकिन ये नियम बदलते नियमों और आवश्यकताओं के मद्देनजर कोड को लंबे समय तक बनाए रखने की दिशा में सक्षम हैं - जो शतरंज के मामले में ऐसा नहीं है।

शतरंज के साथ, सबसे अधिक संभावना दीर्घकालिक रखरखाव पथ यह है कि आपके कार्यक्रम को बेहतर और स्मार्ट बनाने की आवश्यकता है, जिसका अर्थ है कि गति और भंडारण अनुकूलन का प्रभुत्व होगा। उसके लिए, आपको आम तौर पर प्रदर्शन के लिए पठनीयता का त्याग करने वाले व्यापार को बंद करना होगा, और यहां तक कि सबसे अच्छा ओओ डिजाइन अंततः किनारे से जाएगा।

— एरिक Eidt
स्रोत

ध्यान दें कि कई सक्सेफुल गेम्स हुए हैं जो एक कॉन्सेप्ट लेते हैं और फिर कुछ नई चीजों को मिक्स में फेंक देते हैं। यदि आप भविष्य में अपने शतरंज के खेल के साथ ऐसा करना चाहते हैं, तो आपको वास्तव में भविष्य के बदलावों को ध्यान में रखना चाहिए।

— फ्लेटर

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एक सरल लेकिन लचीला इंटरफ़ेस है जो कार्यान्वयन को किसी भी तरह से बोर्ड राज्य को अद्यतन करने की अनुमति देता है, जैसे कि जटिल चालों जैसे कि कास्टलिंग और पदोन्नति। मानक शतरंज के लिए, आपके पास प्रत्येक प्रकार के टुकड़े के लिए एक कार्यान्वयन होगा, लेकिन आप Gameशतरंज के विभिन्न प्रकारों का समर्थन करने के लिए विभिन्न नियमों में भी प्लग इन कर सकते हैं ।

— कैसाब्लांका
स्रोत

दिलचस्प दृष्टिकोण - विचार के लिए अच्छा भोजन

— CanISleepYet

1

मुझे लगता है कि इस उदाहरण में विरासत क्लीनर की पसंद होगी। संरचना थोड़ी अधिक सुरुचिपूर्ण हो सकती है, लेकिन यह मुझे थोड़ा और मजबूर करने के लिए लगता है।

यदि आप अन्य खेलों को विकसित करने की योजना बना रहे थे, जो अलग-अलग व्यवहार करते हैं, जो चल रहे टुकड़ों का उपयोग करते हैं, तो रचना एक बेहतर विकल्प हो सकता है, खासकर यदि आपने प्रत्येक खेल के लिए आवश्यक टुकड़ों को उत्पन्न करने के लिए एक कारखाना पैटर्न नियोजित किया था।

— कर्ट हल्डमैन
स्रोत

2

आप इनहेरिटेंस का उपयोग करके प्रचार से कैसे निपटेंगे?

— कैटरवर्जर

4

@ TheCatWhisperer जब आप शारीरिक रूप से खेल खेल रहे हों तो आप इसे कैसे संभालेंगे ? (उम्मीद है कि आप उस टुकड़े को बदल देंगे - आप मोहरे को फिर से

— तराशेंगे

0

जो निश्चित रूप से "is-a" सिद्धांत का पालन करता है

सही है, इसलिए आप विरासत का उपयोग करें। आप अभी भी अपने टुकड़ा वर्ग के भीतर रचना कर सकते हैं लेकिन कम से कम आपके पास एक रीढ़ होगी। रचना अधिक लचीली है, लेकिन लचीलापन सामान्य रूप से, और निश्चित रूप से इस मामले में अधिक है, क्योंकि किसी के द्वारा एक नए प्रकार के टुकड़े को पेश करने की संभावना है, जिससे आपको अपने कठोर मॉडल को छोड़ने की आवश्यकता होगी। शतरंज का खेल जल्द ही कभी भी बदलने वाला नहीं है। वंशानुक्रम आपको एक मार्गदर्शक मॉडल देता है, कुछ भी संबंधित है, शिक्षण कोड, दिशा। रचना इतनी नहीं, सबसे महत्वपूर्ण डोमेन इकाइयां बाहर खड़ी नहीं होती हैं, यह स्पिनलेस है, आपको कोड को समझने के लिए गेम को समझना होगा।

— मार्टिन मात
स्रोत

इस बिंदु को जोड़ने के लिए धन्यवाद कि रचना के साथ कोड के बारे में तर्क करना कठिन है

— CanISleepYet

0

कृपया यहाँ विरासत का उपयोग न करें। जबकि अन्य उत्तरों में निश्चित रूप से ज्ञान के कई रत्न हैं, यहाँ विरासत का उपयोग करना निश्चित रूप से एक गलती होगी। रचना का उपयोग करने से न केवल आपको उन मुद्दों से निपटने में मदद मिलती है जिनका आप अनुमान नहीं लगाते हैं, लेकिन मैं पहले से ही यहां एक समस्या देख रहा हूं कि विरासत सुशोभित नहीं हो सकती है।

पदोन्नति, जब एक मोहरा अधिक मूल्यवान टुकड़े में परिवर्तित हो जाता है, तो विरासत के साथ एक मुद्दा हो सकता है। तकनीकी रूप से, आप एक टुकड़े को दूसरे के साथ बदलकर इससे निपट सकते हैं, लेकिन इस दृष्टिकोण की सीमाएं हैं। इन सीमाओं में से एक प्रति टुकड़ा आँकड़ों पर नज़र रखने वाली होगी जहाँ आप प्रचार के बारे में जानकारी को रीसेट नहीं करना चाहते (या उन्हें कॉपी करने के लिए अतिरिक्त कोड लिख सकते हैं)।

अब, जहाँ तक आपके प्रश्न में आपकी रचना का डिज़ाइन है, मुझे लगता है कि यह अनावश्यक रूप से जटिल है। मुझे संदेह नहीं है कि आपके पास प्रत्येक कार्रवाई के लिए एक अलग घटक होने की आवश्यकता है और प्रति टुकड़ा प्रकार एक वर्ग से चिपक सकता है। टाइप एनम भी अनावश्यक हो सकता है।

मैं एक Pieceवर्ग को परिभाषित करूंगा (जैसा कि आपके पास पहले से है), साथ ही साथ एक PieceTypeवर्ग भी। PieceTypeवर्ग की परिभाषा इस तरह, के रूप में सभी तरीकों जो एक प्यादा, रानी, ect को परिभाषित करना होगा, CanMoveTo, GetPieceTypeName, ect। तब Pawnऔर Queen, ect वर्ग वस्तुतः PieceTypeवर्ग से विरासत में मिलेगा ।

— TheCatWhisperer
स्रोत

3

पदोन्नति और प्रतिस्थापन के साथ आप जो समस्याएं देखते हैं, वे तुच्छ हैं, आईएमओ। चिंताओं का पृथक्करण बहुत अनिवार्य है कि इस तरह के "प्रति टुकड़ा ट्रैकिंग" (या जो भी हो) को स्वतंत्र रूप से वैसे भी संभाला जाए । ... कोई संभावित लाभ जो आपके समाधान प्रदान करता है, वह उन काल्पनिक चिंताओं से ग्रहण किया जाता है जिन्हें आप पता करने की कोशिश कर रहे हैं, आईएमओ।

— svidgen

5

स्पष्ट करने के लिए: निस्संदेह आपके प्रस्तावित समाधान के लिए कुछ गुण हैं। लेकिन, वे आपके उत्तर को खोजने में कठिन हैं, जो मुख्य रूप से उन समस्याओं पर केंद्रित है जो वास्तव में "इनहेरिटेंस सॉल्यूशन" को हल करना आसान है। ... जो भी गुण आप अपनी राय के बारे में संवाद करने की कोशिश कर रहे हैं, उस तरह के अवरोध (मेरे लिए वैसे भी)।

— svidgen

1

यदि Pieceवर्चुअल नहीं है, तो मैं इस समाधान से सहमत हूं। जबकि कक्षा का डिज़ाइन सतह पर थोड़ा अधिक जटिल लग सकता है, मुझे लगता है कि कार्यान्वयन समग्र रूप से सरल होगा। मुख्य चीजें जो इसके साथ जुड़ी होंगी Pieceऔर नहीं PieceTypeहैं, यह पहचान है और संभवतः इसका चाल इतिहास।

— जिमीजम्स

1

@svidgen एक कार्यान्वयन जो एक रचित टुकड़े का उपयोग करता है और एक कार्यान्वयन जो वंशानुक्रम-आधारित टुकड़ा का उपयोग करता है, मूल रूप से इस समाधान में वर्णित विवरणों से अलग दिखाई देगा। यह संरचना समाधान अप्रत्यक्ष स्तर का एकल स्तर जोड़ता है। मैं नहीं देखता कि बचने लायक कुछ है।

— जिमीजैम

2

@ जिम्मीजैम राइट लेकिन, कई टुकड़ों के मूव हिस्ट्री को ट्रैक करने और सहसंबद्ध करने की आवश्यकता है - ऐसा कुछ भी नहीं जिसके लिए कोई भी टुकड़ा IMO के लिए जिम्मेदार हो। यदि आप चीजों के ठोस प्रकार में हैं तो यह एक "अलग चिंता" है।

— svidgen

0

मेरे दृष्टिकोण से, प्रदान की गई जानकारी के साथ, यह जवाब देना बुद्धिमानी नहीं है कि विरासत या रचना को जाने का रास्ता होना चाहिए या नहीं।

ऑब्जेक्ट-ओरिएंटेड डिज़ाइनर के टूलबेल में इनहेरिटेंस और कंपोज़िशन केवल उपकरण हैं।
आप समस्या के क्षेत्र के लिए कई अलग-अलग मॉडल डिजाइन करने के लिए इन उपकरणों का उपयोग कर सकते हैं।
चूंकि कई ऐसे मॉडल हैं जो एक डोमेन का प्रतिनिधित्व कर सकते हैं, आवश्यकताओं के डिजाइनर के दृष्टिकोण के आधार पर, आप कार्यात्मक रूप से समकक्ष मॉडल के साथ आने के लिए विरासत और संरचना को कई तरीकों से जोड़ सकते हैं।

आपके मॉडल पूरी तरह से अलग हैं, पहले एक में आप शतरंज के टुकड़ों की अवधारणा के आसपास मॉडलिंग करते थे, दूसरे में टुकड़ों के आंदोलन की अवधारणा के आसपास। वे कार्यात्मक रूप से समतुल्य हो सकते हैं, और मैं उस एक को चुनूंगा जो डोमेन का बेहतर प्रतिनिधित्व करता है और मुझे इसके बारे में अधिक आसानी से कारण देता है।

इसके अलावा, आपके दूसरे डिज़ाइन में, यह तथ्य कि आपकी Pieceकक्षा में एक typeफ़ील्ड है, स्पष्ट रूप से पता चलता है कि यहाँ एक डिज़ाइन समस्या है क्योंकि टुकड़ा खुद कई प्रकार का हो सकता है। क्या यह इस तरह से नहीं लगता है कि शायद कुछ प्रकार की विरासत का उपयोग करना चाहिए, जहां टुकड़ा ही प्रकार है?

तो, आप देखते हैं, अपने समाधान के बारे में बहस करना बहुत कठिन है। क्या मायने नहीं रखता है कि आपने विरासत या रचना का उपयोग किया है, लेकिन क्या आपका मॉडल समस्या के क्षेत्र को सटीक रूप से दर्शाता है और यदि यह इसके बारे में तर्क करने और इसे लागू करने के लिए उपयोगी है।

विरासत और संरचना का सही उपयोग करने के लिए कुछ अनुभव होता है, लेकिन वे पूरी तरह से अलग उपकरण हैं और मुझे विश्वास नहीं है कि कोई एक को दूसरे के साथ "स्थानापन्न" कर सकता है, हालांकि मैं इस बात से सहमत हो सकता हूं कि एक प्रणाली को पूरी तरह से सिर्फ रचना का उपयोग करके डिजाइन किया जा सकता है।

— edalorzo
स्रोत

आप एक अच्छा बिंदु बनाते हैं कि यह वह मॉडल है जो महत्वपूर्ण है और उपकरण नहीं है। निरर्थक प्रकार के संबंध में वंशानुक्रम वास्तव में मदद करता है? उदाहरण के लिए अगर मैं सभी पंजे को उजागर करना चाहता हूं या जांचता हूं कि क्या एक टुकड़ा राजा था तो क्या मुझे कुछ कास्टिंग की आवश्यकता नहीं होगी?

— CanisleepYet

-1

खैर, मैं न तो सुझाव देता हूं।

जबकि ऑब्जेक्ट-ओरिएंटेशन एक अच्छा उपकरण है, और अक्सर चीजों को सरल बनाने में मदद करता है, टूलशेड में यह एकमात्र उपकरण नहीं है।

इसके बजाय, एक बोर्ड क्लास को लागू करने पर विचार करें, जिसमें एक साधारण बायटेरेप शामिल है।
इसकी व्याख्या करना, और उस पर चीजों की गणना करना सदस्य-कार्यों में बिट-मास्किंग और स्विचिंग का उपयोग करके किया जाता है।

स्वामी के लिए MSB का उपयोग करें, टुकड़े के लिए 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); }
};

— Deduplicator
स्रोत

दिलचस्प ... और उपयुक्त पर विचार यह एक सी ++ सवाल है। लेकिन, C ++ प्रोग्रामर नहीं होने के कारण, यह मेरी पहली (या दूसरी या तीसरी ) वृत्ति नहीं होगी! ... यह शायद सबसे C ++ उत्तर हो सकता है यहाँ!

— svidgen

7

यह एक माइक्रोप्टीमाइजेशन है जिसका कोई वास्तविक अनुप्रयोग पालन नहीं करना चाहिए।

— रेयान

@ LieRyan यदि आपके पास OOP है, तो सब कुछ एक वस्तु की तरह महकता है। और क्या यह वास्तव में है कि "माइक्रो" एक दिलचस्प सवाल है। आप इसके साथ क्या करते हैं , इसके आधार पर , यह काफी महत्वपूर्ण हो सकता है।

— डेडुप्लिकेटर

हे ... कि कहा , सी ++ है वस्तु उन्मुख। मुझे लगता है कि एक कारण है कि ओपी सिर्फ सी के बजाय सी ++ का उपयोग कर रहा है ।

— svidgen

3

यहां मैं OOP की कमी के बारे में कम चिंतित हूं, लेकिन कोड को थोड़ा ट्विडलिंग के साथ बाधित कर रहा हूं। जब तक आप 8-बिट निन्टेंडो के लिए कोड नहीं लिख रहे हैं या आप एल्गोरिदम लिख रहे हैं, जिसके लिए बोर्ड राज्य की लाखों प्रतियों से निपटने की आवश्यकता है, यह समय से पहले microoptimization, और असावधान है। सामान्य परिदृश्यों में, यह संभवत: वैसे भी तेज़ नहीं होगा क्योंकि अनलगंटेड बिट एक्सेस के लिए अतिरिक्त बिट-ऑपरेशंस की आवश्यकता होती है।

— रेयान