การใช้ตัวดำเนินการแคสต์อย่างชัดเจนของฉันนั้นสมเหตุสมผลหรือแฮ็คที่ไม่ดี?

ฉันมีวัตถุขนาดใหญ่:

class BigObject{
    public int Id {get;set;}
    public string FieldA {get;set;}
    // ...
    public string FieldZ {get;set;}
}

และวัตถุที่เหมือน DTO เฉพาะด้าน:

class SmallObject{
    public int Id {get;set;}
    public EnumType Type {get;set;}
    public string FieldC {get;set;}
    public string FieldN {get;set;}
}

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

var small = (SmallObject) bigOne;
passSmallObjectToSomeone(small);

มันถูกใช้งานโดยใช้โอเปอเรเตอร์ที่ชัดเจน:

public static explicit operator SmallObject(BigObject big){
    return new SmallObject{
        Id = big.Id,
        FieldC = big.FieldC,
        FieldN = big.FieldN,
        EnumType = MyEnum.BigObjectSpecific
    };
}

ตอนนี้ฉันสามารถสร้างSmallObjectFactoryชั้นเรียนด้วยFromBigObject(BigObject big)วิธีการที่จะทำสิ่งเดียวกันเพิ่มไปยังการฉีดพึ่งพาและเรียกมันว่าเมื่อจำเป็น ... แต่สำหรับฉันดูเหมือนว่ายิ่งซับซ้อนและไม่จำเป็น

ป.ล. ฉันไม่แน่ใจว่าสิ่งนี้เกี่ยวข้องหรือไม่ แต่จะมีสิ่งใดบ้างOtherBigObjectที่สามารถเปลี่ยนเป็นSmallObjectตั้งค่าต่างEnumTypeๆ ได้

ไม่มีคำตอบอื่นใดที่ถูกต้องในความคิดที่ต่ำต้อยของฉัน ในคำถาม stackoverflowนี้คำตอบที่ได้รับการโหวตสูงสุดระบุว่ารหัสการจับคู่ควรเก็บไว้นอกโดเมน เพื่อตอบคำถามของคุณไม่ได้ - การใช้งานตัวดำเนินการส่งของคุณไม่ดีนัก ฉันขอแนะนำให้ทำแผนที่บริการซึ่งตั้งอยู่ระหว่าง DTO ของคุณกับคุณโดเมนวัตถุหรือคุณสามารถใช้ automapper สำหรับสิ่งนั้น

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

ฉันอยากจะแนะนำ.ToSmallObject()วิธีการแทน มันชัดเจนเกี่ยวกับสิ่งที่เกิดขึ้นจริงและเป็น verbose

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

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

หมายเหตุวิธีนี้BigObjectไม่ได้ขึ้นอยู่กับSmallObjectแต่วิธีอื่น ๆ (ตามที่ควรเป็นในความเห็นต่ำต้อยของฉัน)

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

ฉันขอแนะนำให้เป็นข้อกำหนดที่ให้x=(SomeType)foo;ตามมาในภายหลังy=(SomeType)foo;ด้วยทั้ง casts ที่นำไปใช้กับวัตถุเดียวกันx.Equals(y)ควรเสมอและตลอดไปจะเป็นจริงแม้ว่าวัตถุที่มีปัญหาจะได้รับการแก้ไขระหว่างสอง casts สถานการณ์ดังกล่าวสามารถนำไปใช้ได้หากเช่นมีวัตถุคู่หนึ่งชนิดที่แตกต่างกันซึ่งแต่ละรายการมีการอ้างอิงที่ไม่เปลี่ยนรูปแบบไปยังอีกอันหนึ่งและการส่งวัตถุทั้งสองไปที่อีกประเภทหนึ่งจะส่งคืนอินสแตนซ์ที่จับคู่ นอกจากนี้ยังสามารถนำไปใช้กับประเภทที่ทำหน้าที่เป็นตัวห่อกับวัตถุที่ไม่แน่นอนได้หากว่าตัวตนของวัตถุที่ถูกห่อเป็นสิ่งที่ไม่สามารถเปลี่ยนแปลงได้และสิ่งห่อหุ้มสองประเภทที่เหมือนกันจะรายงานตัวเองว่าเท่าเทียมกัน

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

มันอาจจะไม่เป็นไร

ปัญหาเกี่ยวกับตัวอย่างของคุณคือคุณใช้ชื่อ example-ish ดังกล่าว พิจารณา:

SomeMethod(long longNum)
{
  int num = (int)longNum;
  /* ... */

ตอนนี้เมื่อคุณได้ความคิดที่ดีสิ่งที่ยาวและintวิธีแล้วทั้งหล่อโดยนัยของintการlongและนักแสดงอย่างชัดเจนจากlongการintเป็นที่เข้าใจมาก นอกจากนี้ยังเป็นที่เข้าใจวิธีการที่3จะกลายเป็นและเป็นเพียงวิธีการทำงานอีกด้วย3 3เป็นที่เข้าใจได้ว่ามันจะล้มเหลวอย่างไรint.MaxValue + 1ในบริบทที่ตรวจสอบ แม้ว่ามันจะทำงานกับint.MaxValue + 1บริบทที่ไม่ได้ตรวจสอบเพื่อให้ได้ผลลัพธ์int.MinValueไม่ใช่สิ่งที่ยากที่สุดในการติดตาม

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

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