Khi nào nên dừng thừa kế?

Ngày xưa tôi đã hỏi một câu hỏi về Stack Overflow về tính kế thừa.

Tôi đã nói tôi thiết kế động cơ cờ vua theo kiểu OOP. Vì vậy, tôi thừa hưởng tất cả các phần của tôi từ lớp trừu tượng Piece nhưng kế thừa vẫn đi. Hãy để tôi hiển thị bằng mã

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

public abstract class Pawn: Piece {}

public class WhitePawn :Pawn {}

public class BlackPawn:Pawn {}

Các lập trình viên đã được tìm thấy thiết kế của tôi một chút so với kỹ thuật và đề nghị loại bỏ các lớp mảnh màu và giữ màu mảnh như một thành viên thuộc tính như dưới đây.

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

Bằng cách này, Piece có thể biết màu sắc của mình. Sau khi thực hiện tôi đã thấy việc thực hiện của tôi diễn ra như dưới đây.

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
        {

        }
    }
}

Bây giờ tôi thấy rằng giữ thuộc tính màu gây ra nếu các câu lệnh trong triển khai. Nó làm cho tôi cảm thấy chúng ta cần các mảnh màu cụ thể trong hệ thống phân cấp thừa kế.

Trong trường hợp như vậy, bạn sẽ có các lớp như WhitePawn, BlackPawn hay bạn sẽ thiết kế bằng cách giữ thuộc tính Color?

Không thấy vấn đề như vậy, bạn muốn bắt đầu thiết kế như thế nào? Giữ màu tài sản hoặc có giải pháp thừa kế?

Chỉnh sửa: Tôi muốn xác định rằng ví dụ của tôi có thể không hoàn toàn khớp với ví dụ thực tế. Vì vậy, trước khi cố gắng đoán chi tiết thực hiện chỉ cần tập trung câu hỏi.

Tôi thực sự chỉ đơn giản là hỏi nếu sử dụng thuộc tính Color sẽ gây ra nếu câu lệnh tốt hơn để sử dụng kế thừa?

Hãy tưởng tượng bạn thiết kế một ứng dụng có chứa phương tiện. Bạn có tạo ra một cái gì đó như thế này?

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

Trong cuộc sống thực, màu sắc là tài sản của một vật thể (có thể là ô tô hoặc quân cờ) và phải được đại diện bởi một tài sản.

Là MakeMovevà TakeBackMovekhác nhau cho người da đen và người da trắng? Hoàn toàn không: các quy tắc đều giống nhau cho cả hai người chơi, điều đó có nghĩa là hai phương thức đó sẽ hoàn toàn giống nhau đối với người da đen và người da trắng , điều đó có nghĩa là bạn đang thêm một điều kiện mà bạn không cần nó.

Mặt khác, nếu bạn có WhitePawnvà BlackPawn, tôi sẽ không ngạc nhiên nếu sớm hay muộn bạn sẽ viết:

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

hoặc thậm chí một cái gì đó như:

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.

Điều bạn nên tự hỏi mình là tại sao bạn thực sự cần những câu nói đó trong lớp Cầm đồ của bạn:

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

    }
    else
    {
    }

Tôi khá chắc chắn rằng nó sẽ đủ để có một bộ chức năng nhỏ như

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

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

trong lớp Piece của bạn và thực hiện tất cả các hàm trong Pawn(và các dẫn xuất khác của Piece) bằng cách sử dụng các hàm đó, mà không bao giờ có bất kỳ ifcâu lệnh nào ở trên. Chỉ có ngoại lệ có thể là chức năng xác định hướng di chuyển cho Cầm đồ bằng màu sắc của nó, vì điều này là đặc trưng cho cầm đồ, nhưng trong hầu hết các trường hợp khác, bạn sẽ không cần bất kỳ mã cụ thể màu nào.

Một câu hỏi thú vị khác là liệu bạn có thực sự nên có các lớp con khác nhau cho các loại mảnh khác nhau không. Điều đó có vẻ hợp lý và tự nhiên đối với tôi, vì các quy tắc cho các bước di chuyển là khác nhau và bạn chắc chắn có thể thực hiện điều này bằng cách sử dụng các hàm quá tải khác nhau cho từng loại mảnh.

Tất nhiên, người ta có thể cố gắng để mô hình này một cách chung chung hơn, bằng cách tách các thuộc tính của các mảnh từ quy tắc di chuyển của họ, nhưng điều này có thể kết thúc trong một lớp trừu tượng MovingRulevà một hệ thống phân cấp lớp MovingRulePawn, MovingRuleQueen... Tôi sẽ không bắt đầu nó mà cách, vì nó có thể dễ dàng dẫn đến một hình thức kỹ thuật quá mức khác.

Kế thừa không hữu ích khi tiện ích mở rộng không ảnh hưởng đến khả năng bên ngoài của đối tượng .

Thuộc tính Color không ảnh hưởng đến cách sử dụng đối tượng Piece . Ví dụ: tất cả các mảnh có thể gọi một phương thức moveForward hoặc moveBackwards (ngay cả khi di chuyển không hợp pháp), nhưng logic đóng gói của Piece sử dụng thuộc tính Color để xác định giá trị tuyệt đối đại diện cho chuyển động tiến hoặc lùi (-1 hoặc + 1 trên "trục y"), theo như API của bạn có liên quan, siêu lớp và các lớp con của bạn là các đối tượng giống hệt nhau (vì tất cả chúng đều phơi bày các phương thức giống nhau).

Cá nhân, tôi định nghĩa một số hằng đại diện cho từng loại mảnh, sau đó sử dụng câu lệnh chuyển đổi để phân nhánh thành các phương thức riêng trả lại các di chuyển có thể cho trường hợp "này".

Cá nhân tôi sẽ không thừa hưởng bất cứ điều gì từ Piecetất cả, bởi vì tôi không nghĩ rằng bạn có được bất cứ điều gì từ việc đó. Có lẽ một mảnh không thực sự quan tâm đến cách nó di chuyển, chỉ có hình vuông nào là đích đến hợp lệ cho bước di chuyển tiếp theo của nó.

Có lẽ bạn có thể tạo Máy tính Di chuyển hợp lệ , biết các mẫu chuyển động có sẵn cho một loại mảnh và có thể truy xuất danh sách các ô vuông đích hợp lệ, ví dụ:

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

Trong câu trả lời này, tôi cho rằng bằng "công cụ cờ vua", tác giả của câu hỏi có nghĩa là "cờ vua AI", không chỉ đơn thuần là một công cụ xác nhận di chuyển.

Tôi nghĩ rằng sử dụng OOP cho các mảnh và chuyển động hợp lệ của chúng là một ý tưởng tồi vì hai lý do:

1. Sức mạnh của một động cơ cờ vua phụ thuộc rất nhiều vào tốc độ nó có thể điều khiển các bàn cờ , xem ví dụ: các đại diện cho bảng chương trình Cờ vua . Xem xét mức độ tối ưu hóa mà bài viết này mô tả, tôi không nghĩ rằng một cuộc gọi chức năng thông thường là giá cả phải chăng. Một cuộc gọi đến một phương thức ảo sẽ thêm một mức độ gián tiếp và phải chịu một hình phạt hiệu suất cao hơn nữa. Chi phí của OOP không phải là giá cả phải chăng ở đó.
2. Những lợi ích của OOP như khả năng mở rộng là không thể sử dụng cho các quân cờ, vì cờ vua không có khả năng sớm có được quân cờ mới. Một sự thay thế khả thi cho hệ thống phân cấp kiểu dựa trên thừa kế bao gồm sử dụng enums và switch. Rất thấp công nghệ và giống như C, nhưng khó đánh bại hiệu suất-khôn ngoan.

Di chuyển ra khỏi các cân nhắc hiệu suất, bao gồm cả màu sắc của mảnh trong phân cấp loại theo ý kiến ​​của tôi là một ý tưởng tồi. Bạn sẽ thấy mình trong các tình huống mà bạn cần kiểm tra xem hai mảnh có màu khác nhau hay không, ví dụ để chụp. Kiểm tra điều kiện này được thực hiện dễ dàng bằng cách sử dụng một tài sản. Làm điều đó bằng cách sử dụng is WhitePiece-tests sẽ là xấu hơn so với.

Ngoài ra còn có một lý do thực tế khác để tránh di chuyển thế hệ di chuyển sang các phương pháp cụ thể, cụ thể là các phần khác nhau có chung các bước di chuyển, ví dụ như tân binh và nữ hoàng. Để tránh mã trùng lặp, bạn sẽ phải tính toán mã phổ biến thành phương thức cơ bản và có một cuộc gọi tốn kém khác.

Điều đó đang được nói, nếu đó là công cụ cờ vua đầu tiên bạn đang viết, tôi chắc chắn sẽ khuyên bạn nên tuân thủ các nguyên tắc lập trình sạch sẽ và tránh các thủ thuật tối ưu hóa được mô tả bởi tác giả của Crafty. Đối phó với các đặc điểm cụ thể của các quy tắc cờ vua (đúc, thăng cấp, vượt qua) và các kỹ thuật AI phức tạp (bảng băm, cắt alpha-beta) là đủ thách thức.