ควรหยุดการสืบทอดเมื่อใด

กาลครั้งหนึ่งนานมานี้ฉันถามคำถามเกี่ยวกับการโอเวอร์โฟลว์เกี่ยวกับการสืบทอด

ฉันได้กล่าวว่าฉันออกแบบเครื่องมือหมากรุกในแบบ OOP ดังนั้นฉันจึงรับช่วงต่อของฉันทั้งหมดจากระดับนามธรรมของ Piece แต่การสืบทอดยังคงดำเนินต่อไป ให้ฉันแสดงด้วยรหัส

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();
}

ด้วยวิธีนี้ Piece สามารถรู้สีของเขาได้ หลังจากการนำไปใช้ฉันได้เห็นการดำเนินการของฉันเป็นไปดังนี้

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
        {

        }
    }
}

ตอนนี้ฉันเห็นแล้วว่าให้คุณสมบัติของสีทำให้เกิดข้อความสั่งในการนำไปใช้งาน มันทำให้ฉันรู้สึกว่าเราต้องการชิ้นสีเฉพาะในลำดับชั้นการสืบทอด

ในกรณีเช่นนี้คุณจะมีคลาสเช่น WhitePawn, BlackPawn หรือคุณจะไปที่การออกแบบโดยการรักษาคุณสมบัติของสี?

หากไม่เห็นปัญหาดังกล่าวคุณจะเริ่มออกแบบได้อย่างไร รักษาคุณสมบัติสีหรือมีวิธีแก้ปัญหาการสืบทอดอยู่หรือไม่

แก้ไข:ฉันต้องการระบุว่าตัวอย่างของฉันอาจไม่ตรงกับตัวอย่างชีวิตจริงทั้งหมด ดังนั้นก่อนที่จะพยายามเดารายละเอียดการใช้งานก็แค่ตั้งคำถาม

ฉันแค่ถามว่าการใช้คุณสมบัติสีจะทำให้เกิดถ้างบดีกว่าที่จะใช้การสืบทอด?

ลองนึกภาพคุณออกแบบโปรแกรมที่มียานพาหนะ คุณสร้างบางสิ่งเช่นนี้หรือไม่?

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.

สิ่งที่คุณควรถามตัวเองคือเหตุผลที่คุณต้องการข้อความเหล่านี้ในชั้นเรียนจำนำของคุณ:

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

    }
    else
    {
    }

ฉันค่อนข้างแน่ใจว่ามันจะเพียงพอที่จะมีฟังก์ชั่นชุดเล็ก ๆ

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

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

ในคลาส Piece ของคุณและใช้ฟังก์ชั่นทั้งหมดในPawn(และการสืบทอดอื่น ๆ ของPiece) โดยใช้ฟังก์ชั่นเหล่านั้นโดยไม่ต้องมีข้อความใด ๆifข้างต้น ข้อยกเว้นเท่านั้นอาจเป็นฟังก์ชั่นในการกำหนดทิศทางการย้ายสำหรับการจำนำด้วยสีของมันเนื่องจากเป็นแบบเฉพาะสำหรับการจำนำ แต่ในกรณีอื่นเกือบทั้งหมดคุณไม่จำเป็นต้องใช้รหัสเฉพาะสีใด ๆ

คำถามที่น่าสนใจอื่น ๆ คือถ้าคุณควรมีคลาสย่อยที่แตกต่างกันสำหรับชิ้นส่วนที่แตกต่างกันเลย มันดูสมเหตุสมผลและเป็นธรรมชาติสำหรับฉันเนื่องจากกฎสำหรับการเคลื่อนไหวของแต่ละชิ้นนั้นแตกต่างกันและคุณสามารถใช้มันได้อย่างแน่นอนโดยใช้ฟังก์ชั่นโอเวอร์โหลดที่แตกต่างกันสำหรับชิ้นส่วนแต่ละประเภท

แน่นอนหนึ่งได้พยายามที่จะจำลองนี้ในทางทั่วไปมากขึ้นโดยการแยกคุณสมบัติของชิ้นส่วนจากกฎการเคลื่อนย้ายของพวกเขา แต่ตอนนี้อาจจะจบในระดับนามธรรมMovingRuleและลำดับชั้นประเภทรองMovingRulePawn, MovingRuleQueen... ฉันจะไม่เริ่มต้นที่ วิธีเนื่องจากมันสามารถนำไปสู่รูปแบบอื่นของวิศวกรรมที่เกินได้

มรดกไม่เป็นประโยชน์เมื่อขยายไม่ได้ส่งผลกระทบต่อวัตถุความสามารถภายนอก

สถานที่ให้บริการสีไม่ได้ส่งผลกระทบต่อวิธีการที่วัตถุชิ้นจะถูกนำมาใช้ ตัวอย่างเช่นชิ้นส่วนทั้งหมดสามารถเรียกใช้เมธอด moveForward หรือ moveBackwards (แม้ว่าการย้ายจะไม่ถูกกฎหมาย) แต่ตรรกะที่ห่อหุ้มของ Piece ใช้คุณสมบัติ Color เพื่อกำหนดค่าสัมบูรณ์ที่แสดงถึงการเคลื่อนที่ไปข้างหน้าหรือข้างหลัง (-1 หรือ + 1 บน "แกน y") ตราบใดที่ API ของคุณเกี่ยวข้องซูเปอร์คลาสและคลาสย่อยของคุณเป็นวัตถุที่เหมือนกัน (เนื่องจากพวกเขาทั้งหมดเปิดเผยวิธีการเดียวกัน)

โดยส่วนตัวแล้วฉันจะกำหนดค่าคงที่บางอย่างที่เป็นตัวแทนของแต่ละประเภทของชิ้นส่วนจากนั้นใช้คำสั่งสลับเพื่อแยกเป็นวิธีส่วนตัวที่คืนค่าการย้ายที่เป็นไปได้สำหรับอินสแตนซ์ "นี้"

โดยส่วนตัวแล้วฉันจะไม่รับสิ่งใดเลย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) {}
}

ในคำตอบนี้ฉันสมมติว่าโดย "เครื่องมือหมากรุก" ผู้เขียนคำถามหมายถึง "หมากรุก AI" ไม่ใช่เครื่องมือตรวจสอบความเคลื่อนไหว

ฉันคิดว่าการใช้ OOP เป็นชิ้น ๆ และการเคลื่อนไหวที่ถูกต้องเป็นความคิดที่ไม่ดีด้วยเหตุผลสองประการ:

1. ความแรงของเครื่องยนต์หมากรุกสูงขึ้นอยู่กับวิธีการที่รวดเร็วที่จะสามารถจัดการกับผ้าดูเช่นหมากรุกเป็นตัวแทนคณะกรรมการโครงการ เมื่อพิจารณาถึงระดับของการปรับให้เหมาะสมที่บทความนี้อธิบายไว้ฉันไม่คิดว่าการเรียกใช้ฟังก์ชั่นทั่วไปนั้นมีราคาไม่แพง การเรียกใช้เมธอดเสมือนจะเพิ่มระดับของการอ้อมและทำให้เกิดการลงโทษประสิทธิภาพที่สูงขึ้น ค่าใช้จ่ายของ OOP นั้นไม่แพง
2. ประโยชน์ของ OOP เช่นความสามารถในการขยายนั้นไม่มีประโยชน์สำหรับชิ้นส่วนเนื่องจากหมากรุกไม่น่าจะมีชิ้นส่วนใหม่ ๆ ในเวลาไม่นาน ทางเลือกที่ทำงานได้กับลำดับชั้นของชนิดอิงตามการสืบทอดรวมถึงการใช้ enums และสวิตช์ เทคโนโลยีต่ำมากและเหมือน C แต่ยากที่จะเอาชนะประสิทธิภาพฉลาด

การย้ายออกจากการพิจารณาเกี่ยวกับประสิทธิภาพการทำงานรวมถึงสีของชิ้นส่วนในลำดับชั้นของประเภทเป็นความคิดที่ไม่ดีของฉัน คุณจะพบว่าตัวเองอยู่ในสถานการณ์ที่คุณต้องตรวจสอบว่ามีสองชิ้นที่มีสีแตกต่างกันหรือไม่ตัวอย่างเช่นการจับภาพ การตรวจสอบสภาพนี้ทำได้ง่าย ๆ โดยใช้คุณสมบัติ การทำโดยใช้การis WhitePieceทดสอบจะเป็นสิ่งที่ไม่ดีในการเปรียบเทียบ

นอกจากนี้ยังมีเหตุผลในทางปฏิบัติอีกประการหนึ่งสำหรับการหลีกเลี่ยงการเคลื่อนย้ายการสร้างการเคลื่อนไหวไปยังวิธีการเฉพาะสำหรับชิ้นงานนั่นคือชิ้นส่วนที่แตกต่างกันมีการเคลื่อนไหวร่วมกันเช่น rooks และ queens เพื่อหลีกเลี่ยงรหัสที่ซ้ำกันคุณจะต้องแยกแยะรหัสทั่วไปให้เป็นวิธีการพื้นฐานและยังมีการโทรที่มีค่าใช้จ่ายสูง

ถ้าหากมันเป็นเอ็นจิ้นหมากรุกตัวแรกที่คุณเขียนฉันจะแนะนำให้ใช้หลักการเขียนโปรแกรมที่สะอาดและหลีกเลี่ยงเทคนิคการปรับให้เหมาะสมที่อธิบายโดยผู้เขียน Crafty การจัดการกับกฎเฉพาะของหมากรุก (การขว้างการส่งเสริมการเล่นการพนัน) และเทคนิค AI ที่ซับซ้อน (กระดานแฮชบอร์ดการตัดอัลฟ่า - เบต้า) นั้นท้าทายพอ