Kalıtım ne zaman durdurulur?

Bir zamanlar Stack Overflow ile ilgili miras hakkında bir soru sordum .

Satranç motorunu OOP tarzında tasarladığımı söyledim. Bu yüzden bütün parçalarımı Parça soyut sınıfından miras alıyorum ama kalıtım hala devam ediyor. Kodla göstereyim

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

public abstract class Pawn: Piece {}

public class WhitePawn :Pawn {}

public class BlackPawn:Pawn {}

Programcılar tasarımımı mühendislik üzerine biraz buldular ve renkli parça sınıflarını kaldırmayı ve parça rengini aşağıdaki gibi bir özellik üyesi olarak tutmayı önerdiler.

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

Bu şekilde Piece rengini bilebilir. Uygulamadan sonra uygulamamın aşağıdaki gibi gittiğini gördüm.

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
        {

        }
    }
}

Şimdi görüyorum ki renk özelliğini uygulamalarda if ifadelerine neden oluyor. Kalıtım hiyerarşisinde belirli renk parçalarına ihtiyacımız olduğunu hissettiriyor.

Böyle bir durumda WhitePawn, BlackPawn gibi sınıflarınız olur mu veya Color özelliğini tutarak tasarıma gider misiniz?

Böyle bir problem görmeden tasarıma nasıl başlamak istersiniz? Color özelliğini mi yoksa devralma çözümünü mü kullanıyorsunuz?

Düzenleme: Örneğimin gerçek hayat örneğiyle tamamen eşleşmeyebileceğini belirtmek istiyorum. Bu yüzden uygulama detaylarını tahmin etmeden önce sadece soruyu konsantre edin.

Aslında sadece renk özelliği kullanarak ifadeler miras kullanmak daha iyi neden olur diye soruyor?

Araç içeren bir uygulama tasarladığınızı düşünün. Böyle bir şey yaratıyor musunuz?

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

Gerçek hayatta renk, bir nesnenin (araba ya da satranç taşı) bir özelliğidir ve bir özellik tarafından temsil edilmelidir.

Are MakeMoveve TakeBackMovesiyahlar ve beyazlar için farklı? Hiç de değil: kurallar her iki oyuncu için de aynıdır, bu da bu iki yöntemin siyahlar ve beyazlar için tamamen aynı olacağı anlamına gelir, bu da ihtiyacınız olmayan bir koşul eklediğiniz anlamına gelir.

Öte yandan, eğer varsa WhitePawnve BlackPawnyakında veya daha sonra yazacak olursanız şaşırmayacağım:

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

hatta şöyle bir şey:

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.

Kendinize sormanız gereken şey, neden Pawn sınıfınızda bu ifadelere gerçekten ihtiyacınız olduğu:

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

    }
    else
    {
    }

Eminim küçük bir fonksiyon setine sahip olmanın yeterli olacağından eminim

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

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

ve bu ifadeleri kullanarak, yukarıdaki ifadelerden hiçbirine sahip olmadan tüm işlevleri Pawn(ve diğer türevlerini Piece) uygulayabilirsiniz if. Tek istisna, bir Piyonun hareket yönünü rengine göre belirleme işlevi olabilir, çünkü bu piyonlara özgüdür, ancak hemen hemen tüm diğer durumlarda renge özgü bir koda ihtiyacınız yoktur.

Diğer ilginç soru, farklı parçalar için gerçekten farklı alt sınıflara sahip olmanız gerektiğidir. Bu benim için makul ve doğal görünüyor, çünkü her parça için hareket kuralları farklı ve her parça için farklı aşırı yüklenmiş fonksiyonları kullanarak bunu kesinlikle uygulayabilirsiniz.

Tabii ki, kimse onların hareket kurallarından adet özelliklerini ayırarak daha genel bir şekilde bu modellemek için deneyebilirsiniz, ancak bu soyut sınıfta sona erebilir MovingRuleve bir alt sınıf hiyerarşisi MovingRulePawn, MovingRuleQueen... Ben başlatmadım ki kolayca başka bir aşırı mühendislik şekline yol açabilir.

Uzantı, nesnenin dış özelliklerini etkilemediğinde kalıtım o kadar yararlı olmaz .

Color özelliği, bir Piece nesnesinin nasıl kullanılacağını etkilemez . Örneğin, tüm parçalar akla uygun olarak bir moveForward veya moveBackwards yöntemini çağırabilir (taşıma yasal olmasa bile), ancak Parçanın kapsüllenmiş mantığı, ileri veya geri hareketi temsil eden mutlak değeri belirlemek için Color özelliğini kullanır (-1 veya + API'niz söz konusu olduğunda, üst sınıfınız ve alt sınıflarınız özdeş nesnelerdir (hepsi aynı yöntemleri açıkladığından).

Şahsen, her bir parça türünü temsil eden bazı sabitleri tanımlar, sonra "this" örneği için olası hareketleri döndüren özel yöntemlere dalmak için bir switch deyimi kullanırdım.

Şahsen hiçbir şeyden miras kalmazdım Piece, çünkü bunu yapmaktan bir şey kazandığını sanmıyorum. Muhtemelen bir parça nasıl hareket ettiğini umursamaz , sadece hangi kareler bir sonraki hamlesi için geçerli bir varış noktasıdır.

Belki de bir parça türü için mevcut hareket modellerini bilen ve geçerli bir hedef kareler listesi alabilen Geçerli bir Hareket Hesap Makinesi oluşturabilirsiniz.

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

Bu cevapta, "satranç motoru" ile, sorunun yazarı "satranç AI" anlamına geldiğini varsayıyorum, sadece bir hareket doğrulama motoru değil.

Parçalar ve geçerli hareketleri için OOP kullanmanın iki nedenden dolayı kötü bir fikir olduğunu düşünüyorum:

1. Bir satranç motorunun gücü o panoları işlemek mesela görebilirsiniz ne kadar hızlı son derece bağlıdır satranç programı kurulu temsillerini . Bu makalede anlatılan optimizasyon düzeyi göz önüne alındığında, düzenli bir işlev çağrısının uygun olduğunu düşünmüyorum. Sanal bir yönteme yapılan çağrı, bir miktar dolaylılık ekler ve daha da yüksek bir performans cezasına neden olur. OOP maliyeti orada uygun değil.
2. Genişletilebilirlik gibi OOP'nin faydaları, satranç için yakın zamanda yeni parçalar elde edemeyeceği için parçalar için hiçbir faydası yoktur. Kalıtım tabanlı tür hiyerarşisine uygun bir alternatif, numaralandırma ve anahtar kullanmayı içerir. Çok düşük teknoloji ve C benzeri, ancak performans açısından yenilmesi zor.

Tip hiyerarşisindeki parçanın rengi de dahil olmak üzere performansla ilgili hususlardan uzaklaşmak bence kötü bir fikir. Kendinizi, örneğin çekim için iki parçanın farklı renklere sahip olup olmadığını kontrol etmeniz gereken durumlarda bulacaksınız. Bu durumun kontrolü bir özellik kullanılarak kolayca yapılabilir. is WhitePiece-Testler kullanarak bunu yapmak daha çirkin olurdu.

Ayrıca, hamle jenerasyonunun parçaya özgü metotlara geçmekten kaçınmanın başka bir pratik nedeni de vardır, yani farklı parçalar ortak hamleleri paylaşır, örneğin kayalar ve kraliçeler. Yinelenen kodlardan kaçınmak için, ortak kodu temel bir yöntemde çarpanlarına ayırmanız ve başka bir pahalı çağrı yapmanız gerekir.

Bununla birlikte, eğer yazdığınız ilk satranç motoru ise, kesinlikle temiz programlama ilkelerine gitmenizi ve Crafty'nin yazarı tarafından açıklanan optimizasyon numaralarından kaçınmanızı tavsiye ederim. Satranç kurallarının (döküm, promosyon, en-passant) ve karmaşık AI tekniklerinin (hash panoları, alfa-beta kesim) özellikleriyle uğraşmak yeterince zordur.