Quando fermare l'eredità?

Una volta ho fatto una domanda su Stack Overflow sull'ereditarietà.

Ho detto che progetto il motore di scacchi alla moda OOP. Quindi eredito tutti i miei pezzi dalla classe astratta di Piece ma l'eredità continua. Fammi mostrare per codice

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

public abstract class Pawn: Piece {}

public class WhitePawn :Pawn {}

public class BlackPawn:Pawn {}

I programmatori hanno trovato il mio progetto un po 'più ingegneristico e mi hanno suggerito di rimuovere le classi di pezzi colorate e mantenere il colore del pezzo come membro della proprietà come di seguito.

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

In questo modo Piece può conoscere il suo colore. Dopo l'implementazione ho visto che la mia implementazione va come di seguito.

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
        {

        }
    }
}

Ora vedo che mantieni la proprietà color causando if istruzioni nelle implementazioni. Mi fa sentire che abbiamo bisogno di pezzi di colore specifici nella gerarchia ereditaria.

In tal caso avresti lezioni come WhitePawn, BlackPawn o andresti a progettare mantenendo la proprietà Color?

Senza aver visto un tale problema, come vorresti iniziare a progettare? Mantenere la proprietà Color o avere una soluzione ereditaria?

Modifica: voglio specificare che il mio esempio potrebbe non corrispondere completamente all'esempio della vita reale. Quindi, prima di provare a indovinare i dettagli dell'implementazione, basta concentrare la domanda.

In realtà sto semplicemente chiedendo se l'uso della proprietà Color provocherà se le dichiarazioni utilizzeranno meglio l'ereditarietà?

Immagina di progettare un'applicazione che contiene veicoli. Crei qualcosa del genere?

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

Nella vita reale, il colore è una proprietà di un oggetto (un'auto o un pezzo degli scacchi) e deve essere rappresentato da una proprietà.

Sono MakeMovee TakeBackMovediversi per neri e bianchi? Niente affatto: le regole sono le stesse per entrambi i giocatori, il che significa che quei due metodi saranno esattamente gli stessi per neri e bianchi , il che significa che stai aggiungendo una condizione in cui non ne hai bisogno.

D'altra parte, se hai WhitePawne BlackPawn, non sarò sorpreso se prima o poi scriverai:

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

o anche qualcosa di simile:

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.

Quello che dovresti chiederti è perché hai davvero bisogno di quelle affermazioni nella tua classe Pawn:

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

    }
    else
    {
    }

Sono abbastanza sicuro che sarà sufficiente avere un piccolo set di funzioni come

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

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

nella tua classe Piece e implementa tutte le funzioni in Pawn(e le altre derivazioni di Piece) usando quelle funzioni, senza mai avere nessuna di quelle ifaffermazioni sopra. L'unica eccezione può essere la funzione per determinare la direzione di spostamento di una pedina in base al suo colore, poiché è specifica per le pedine, ma in quasi tutti gli altri casi non è necessario alcun codice specifico per il colore.

L'altra domanda interessante è se dovresti davvero avere sottoclassi diverse per diversi tipi di pezzi. Mi sembra ragionevole e naturale, dal momento che le regole per le mosse per ogni pezzo sono diverse e puoi sicuramente implementarlo usando diverse funzioni sovraccaricate per ogni tipo di pezzo.

Naturalmente, si potrebbe tentare di modellare questo in un modo più generico, separando le proprietà dei pezzi dalle loro regole in movimento, ma questo può finire in una classe astratta MovingRulee una gerarchia sottoclasse MovingRulePawn, MovingRuleQueen... non vorrei che avviarlo modo, dal momento che potrebbe facilmente portare a un'altra forma di ingegneria eccessiva.

L'ereditarietà non è utile quando l'estensione non influisce sulle capacità esterne dell'oggetto .

La proprietà Color non influisce sul modo in cui viene utilizzato un oggetto Piece . Ad esempio, tutti i pezzi potrebbero concepibilmente invocare un metodo moveForward o moveBackwards (anche se lo spostamento non è legale), ma la logica incapsulata del pezzo utilizza la proprietà Color per determinare il valore assoluto che rappresenta un movimento in avanti o indietro (-1 o + 1 sull'asse y), per quanto riguarda l'API, la superclasse e le sottoclassi sono oggetti identici (poiché espongono tutti gli stessi metodi).

Personalmente, definirei alcune costanti che rappresentano ogni tipo di pezzo, quindi utilizzare un'istruzione switch per ramificare in metodi privati ​​che restituiscono possibili mosse per "questa" istanza.

Personalmente non erediterei affatto nulla Piece, perché non penso che tu guadagni nulla dal farlo. Presumibilmente un pezzo in realtà non importa come si muove, solo quali quadrati sono una destinazione valida per la sua prossima mossa.

Forse potresti creare un calcolatore di spostamento valido che conosce i modelli di movimento disponibili per un tipo di pezzo ed è in grado di recuperare un elenco di quadrati di destinazione validi, ad esempio

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) {}
}

In questa risposta, suppongo che per "motore di scacchi", l'autore della domanda significhi "AI di scacchi", non semplicemente un motore di validazione delle mosse.

Penso che usare OOP per i pezzi e i loro movimenti validi sia una cattiva idea per due motivi:

1. La forza di un motore di scacchi dipende fortemente dalla velocità con cui può manipolare le scacchiere , vedi ad esempio le rappresentazioni delle scacchiere del programma di scacchi . Considerando il livello di ottimizzazione descritto in questo articolo, non credo che una normale chiamata di funzione sia conveniente. Una chiamata a un metodo virtuale aggiungerebbe un livello di riferimento indiretto e comporterebbe una penalità delle prestazioni ancora più elevata. Il costo di OOP non è conveniente lì.
2. I vantaggi di OOP come l'estensibilità non sono utili per i pezzi, poiché è probabile che gli scacchi non ottengano nuovi pezzi presto. Un'alternativa praticabile alla gerarchia di tipi basata sull'ereditarietà include l'uso di enum e switch. Tecnologia molto bassa e C-like, ma difficile da battere dal punto di vista delle prestazioni.

Allontanarsi da considerazioni sulle prestazioni, incluso il colore del pezzo nella gerarchia dei tipi è secondo me una cattiva idea. Ti troverai in situazioni in cui è necessario verificare se due pezzi hanno colori diversi, ad esempio per la cattura. Il controllo di questa condizione è facilmente eseguibile tramite una proprietà. Farlo usando is WhitePiece-test sarebbe più brutto in confronto.

C'è anche un'altra ragione pratica per evitare di spostare la generazione di mosse verso metodi specifici per pezzo, vale a dire che pezzi diversi condividono mosse comuni, ad esempio torri e regine. Al fine di evitare il codice duplicato, dovresti scomporre il codice comune in un metodo di base e avere un'altra chiamata costosa.

Detto questo, se è il primo motore di scacchi che stai scrivendo, consiglierei sicuramente di seguire principi di programmazione chiari ed evitare i trucchi di ottimizzazione descritti dall'autore di Crafty. Affrontare le specifiche delle regole degli scacchi (castling, promozione, en-passant) e complesse tecniche di intelligenza artificiale (hashing board, alpha-beta cut) è abbastanza impegnativo.