การเขียนโปรแกรมไปยังอินเทอร์เฟซ Data Oriented

มีบางส่วนของ codebase ของเราเขียนในรูปแบบต่อไปนี้:

// IScheduledTask.cs
public interface IScheduledTask
{
    string TaskName { get; set; }
    int TaskPriority { get; set; }
    List<IScheduledTask> Subtasks { get; set; }
    // ... several more properties in this vein
}

// ScheduledTaskImpl.cs
public class ScheduledTaskImpl : IScheduledTask
{
    public string TaskName { get; set; }
    public int TaskPriority { get; set; }
    public List<IScheduledTask> Subtasks { get; set; }
    // ... several more properties in this vein, 
    // perhaps a constructor or two for convenience.
}

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

นี่คือสองเซ็นต์ของฉัน:

• เราไม่แน่ใจว่า DTO จะไม่เคยมีพฤติกรรมอย่างน้อยนิด ดังนั้นสำหรับฉันมีวัตถุที่อาจมีหรือไม่มีพฤติกรรมในอนาคต
• สาเหตุหนึ่งที่เป็นไปได้ของการมีชั้นเรียน แต่เพียงผู้เดียวการดำเนินงานจำนวนมากดังนั้นการขาดของการออกแบบเช่นความล้มเหลวที่จะเห็นว่าScheduledTask, ScheduledJob, ScheduledEvent, ScheduledInspectionฯลฯ ควรจะมีเพียงหนึ่งแยกSchedulableอินเตอร์เฟซที่ทำให้ schedulable implementor ใด ๆ
• การสร้างส่วนต่อประสานแรกนั้นเป็นวิธีปฏิบัติที่ดีมากมันช่วยให้คุณเข้าใจถึงสิ่งที่คุณต้องการ อินเทอร์เฟซจำนวนมากเริ่มต้นโดยไม่มีการใช้งานเลย จากนั้นมีคนเขียนหนึ่งการใช้งานและพวกเขามีสิ่งนั้น สถานะของการใช้งานเพียงอย่างเดียวนั้นชั่วคราวถ้าคุณหลีกเลี่ยงสิ่งที่ฉันพูดถึงในจุดที่สอง คุณจะรู้ได้อย่างไรว่าอินเทอร์เฟซบางตัวไม่เคยมีการใช้งานที่สองในสาม
• ชื่อที่เราเลือกสำหรับอินเทอร์เฟซที่คิดดีมีแนวโน้มที่จะไม่เปลี่ยนแปลงในอนาคตดังนั้นการพึ่งพาอินเทอร์เฟซนั้นจะไม่ได้รับผลกระทบ ในอีกทางหนึ่งชั้นคอนกรีตมีแนวโน้มที่จะเปลี่ยนชื่อเมื่อสิ่งที่สำคัญในทางที่จะดำเนินการเปลี่ยนแปลงตัวอย่างเช่นชั้นคอนกรีตชื่อTaxSheetสามารถเปลี่ยนเป็นSessionAwareTaxSheetเพราะยกเครื่องที่สำคัญได้ทำ แต่อินเตอร์เฟซITaxSheetจะไม่ถูกเปลี่ยนชื่อได้อย่างง่ายดาย

ด้านล่างบรรทัด:

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

ปัญหาเฉพาะที่ฉันเคยเห็นกับ DTOs ที่ใช้อินเตอร์เฟสคือมันอนุญาตสิ่งนี้:

public interface ISomeDTO { string SomeProperty { get; set; }}

public class SomeDTO : ISomeDTO
{
    public string SomeProperty { get; set; }
    string ISomeDTO.SomeProperty { get { /* different behavior */ } set { SomeProperty = value; } }
}

ฉันเห็นรูปแบบนี้ใช้เป็นแฮ็คที่รวดเร็วและสกปรกเพื่อใช้งานพฤติกรรมที่สำคัญบางอย่าง สิ่งนี้นำไปสู่โค้ดที่อาจมีพฤติกรรมที่สับสนมาก:

SomeDTO a = GetSomeDTO();
ISomeDTO ia = a;
Assert.IsTrue(a.SomeProperty == ia.SomeProperty); // assert fails!

นี่เป็นเรื่องยากที่จะรักษาและสร้างความสับสนให้พยายามที่จะแก้ให้หายยุ่งหรือ refactor IMO การเพิ่มพฤติกรรมให้กับ DTO นั้นเป็นการละเมิดหลักการความรับผิดชอบเดียว วัตถุประสงค์ของ DTO คือการแสดงข้อมูลในรูปแบบที่สามารถคงอยู่และมีประชากรโดยเฟรมเวิร์กการคงอยู่

DTO ไม่ใช่โมเดลของโดเมน เราไม่ควรกังวลหาก DTO เป็นโลหิตจาง หากต้องการอ้างอิงการอภิปรายของ Martin Fowler เกี่ยวกับโมเดลโดเมนโลหิตจาง :

นอกจากนี้ยังควรเน้นว่าการใส่พฤติกรรมลงในวัตถุโดเมนไม่ควรขัดแย้งกับแนวทางที่มั่นคงในการใช้เลเยอร์เพื่อแยกตรรกะโดเมนจากสิ่งต่าง ๆ เช่นความคงทนและความรับผิดชอบในการนำเสนอ