ฉันควรใช้วิธีนามธรรมหรือเสมือน?

หากเราสมมติว่ามันไม่เป็นที่พึงปรารถนาสำหรับคลาสฐานที่จะเป็นคลาสอินเตอร์เฟสที่บริสุทธิ์และใช้ 2 ตัวอย่างจากด้านล่างซึ่งเป็นวิธีที่ดีกว่าโดยใช้คำนิยามคลาสของวิธีนามธรรมหรือเสมือน?

• ข้อได้เปรียบของเวอร์ชั่น "นามธรรม" คือมันอาจดูสะอาดและบังคับให้คลาสที่ได้รับมาเพื่อให้การใช้งานมีความหมายอย่างมีความหวัง

• ข้อได้เปรียบของเวอร์ชัน "เวอร์ชวล" คือสามารถดึงโมดูลได้ง่ายและใช้สำหรับการทดสอบโดยไม่ต้องเพิ่มเฟรมพื้นฐานมากมายเหมือนเวอร์ชั่นนามธรรมที่ต้องการ

เวอร์ชั่นบทคัดย่อ:

public abstract class AbstractVersion
{
    public abstract ReturnType Method1();        
    public abstract ReturnType Method2();
             .
             .
    public abstract ReturnType MethodN();

    //////////////////////////////////////////////
    // Other class implementation stuff is here
    //////////////////////////////////////////////
}

รุ่นเสมือน:

public class VirtualVersion
{
    public virtual ReturnType Method1()
    {
        return ReturnType.NotImplemented;
    }

    public virtual ReturnType Method2()
    {
        return ReturnType.NotImplemented;
    }
             .
             .
    public virtual ReturnType MethodN()
    {
        return ReturnType.NotImplemented;
    }

    //////////////////////////////////////////////
    // Other class implementation stuff is here
    //////////////////////////////////////////////
}

การลงคะแนนของฉันหากฉันบริโภคสิ่งของของคุณจะใช้วิธีนามธรรม ที่ไปพร้อมกับ "ล้มเหลวเร็ว" อาจเป็นความเจ็บปวดเวลาประกาศเพื่อเพิ่มวิธีการทั้งหมด (แม้ว่าเครื่องมือ refactoring ที่เหมาะสมจะทำอย่างรวดเร็ว) แต่อย่างน้อยฉันก็รู้ว่าปัญหาคืออะไรทันทีและแก้ไข ฉันต้องการที่จะดีบั๊กมากกว่า 6 เดือนและ 12 คนที่มีการเปลี่ยนแปลงในภายหลังเพื่อดูว่าทำไมเราถึงได้รับข้อยกเว้นที่ไม่ได้ใช้งาน

เวอร์ชันเสมือนเป็นทั้งบั๊กที่มีแนวโน้มและไม่ถูกต้องทางความหมาย

บทคัดย่อกำลังพูดว่า "วิธีนี้ไม่ได้ถูกนำมาใช้ที่นี่คุณต้องใช้มันเพื่อให้การเรียนในชั้นนี้"

เสมือนกำลังพูดว่า "ฉันมีการใช้งานเริ่มต้น แต่คุณสามารถเปลี่ยนฉันหากคุณต้องการ"

หากวัตถุประสงค์สุดท้ายของคุณคือการทดสอบได้ส่วนต่อประสานนั้นเป็นตัวเลือกที่ดีที่สุด (คลาสนี้ทำ x แทนคลาสนี้คือขวาน) คุณอาจต้องแบ่งชั้นเรียนของคุณออกเป็นส่วนประกอบที่เล็กลง แต่สิ่งนี้จะทำงานได้ดี

ขึ้นอยู่กับการใช้ชั้นเรียนของคุณ

หากวิธีการมีการใช้งานที่“ ว่างเปล่า” อย่างสมเหตุสมผลคุณมีวิธีการมากมายและคุณมักจะแทนที่เพียงไม่กี่วิธีการเหล่านั้นก็ใช้virtualวิธีการที่เหมาะสม ตัวอย่างเช่นExpressionVisitorการใช้วิธีนี้

มิฉะนั้นฉันคิดว่าคุณควรใช้abstractวิธีการ

เป็นการดีที่คุณไม่ควรมีวิธีการที่ไม่ได้ใช้ แต่ในบางกรณีนั่นเป็นวิธีที่ดีที่สุด แต่ถ้าคุณตัดสินใจที่จะทำเช่นนั้นวิธีการดังกล่าวควรโยนNotImplementedExceptionไม่คืนค่าพิเศษบางอย่าง

ฉันขอแนะนำให้คุณพิจารณาอีกครั้งว่ามีอินเทอร์เฟซแยกต่างหากที่กำหนดว่าคลาสพื้นฐานของคุณดำเนินการอย่างไรจากนั้นให้คุณทำตามแนวทางนามธรรม

รหัสภาพเช่นนี้:

public interface IVersion
{
    ReturnType Method1();        
    ReturnType Method2();
             .
             .
    ReturnType MethodN();
}

public abstract class AbstractVersion : IVersion
{
    public abstract ReturnType Method1();        
    public abstract ReturnType Method2();
             .
             .
    public abstract ReturnType MethodN();

    //////////////////////////////////////////////
    // Other class implementation stuff is here
    //////////////////////////////////////////////
}

การทำเช่นนี้จะช่วยแก้ปัญหาเหล่านี้ได้:

1. โดยการมีรหัสทั้งหมดที่ใช้วัตถุที่ได้มาจาก AbstractVersion ตอนนี้สามารถนำไปใช้เพื่อรับส่วนต่อประสาน IVersion แทนซึ่งหมายความว่าพวกเขาสามารถทดสอบหน่วยได้ง่ายขึ้น

2. รีลีส 2 ของผลิตภัณฑ์ของคุณสามารถนำอินเตอร์เฟส IVersion2 ไปใช้เพื่อมอบฟังก์ชันการทำงานเพิ่มเติมโดยไม่ทำลายรหัสลูกค้าที่มีอยู่ของคุณ

เช่น.

public interface IVersion
{
    ReturnType Method1();        
    ReturnType Method2();
             .
             .
    ReturnType MethodN();
}

public interface IVersion2
{
    ReturnType Method2_1();
}

public abstract class AbstractVersion : IVersion, IVersion2
{
    public abstract ReturnType Method1();        
    public abstract ReturnType Method2();
             .
             .
    public abstract ReturnType MethodN();
    public abstract ReturnType Method2_1();

    //////////////////////////////////////////////
    // Other class implementation stuff is here
    //////////////////////////////////////////////
}

นอกจากนี้ยังควรอ่านเกี่ยวกับการพึ่งพาการพึ่งพาเช่นกันเพื่อป้องกันไม่ให้คลาสนี้มีการอ้างอิงแบบฮาร์ดโค้ดที่ป้องกันการทดสอบหน่วยที่มีประสิทธิภาพ

การพึ่งพาการพึ่งพาอาศัยอินเทอร์เฟซ นี่เป็นตัวอย่างสั้น ๆ นักเรียนชั้นมีฟังก์ชั่นที่เรียกว่า CreateStudent ที่ต้องใช้พารามิเตอร์ที่ใช้อินเตอร์เฟซ "IReporting" (ด้วยวิธีการ ReportAction) หลังจากสร้างนักเรียนมันจะเรียก ReportAction บนพารามิเตอร์คลาสคอนกรีต หากระบบถูกตั้งค่าให้ส่งอีเมลหลังจากสร้างนักเรียนเราจะส่งคลาสคอนกรีตที่ส่งอีเมลในการใช้งาน ReportAction หรือเราสามารถส่งคลาสคอนกรีตอีกอันที่ส่งเอาต์พุตไปยังเครื่องพิมพ์ในการใช้งาน ReportAction ยอดเยี่ยมสำหรับการใช้รหัสซ้ำ