ควรระบุ ID ธุรกิจที่เป็นที่รู้จักกันดีของกิจการด้วยประเภทเฉพาะใน DDD / OOP หรือไม่

9

ในแง่การปฏิบัติมันหมายถึงการใช้กำหนดเอง (ไม่เปลี่ยนรูป) classมากกว่าstringหรือบางประเภทดั้งเดิมอื่น ๆ

ตัวอย่าง:

สำนักพิมพ์: หมายเลขหนังสือมาตรฐานสากล
การเงิน: หมายเลขประจำตัวของหลักทรัพย์ระหว่างประเทศ

ข้อดี:

สามารถมั่นใจได้ว่ารูปแบบของตัวระบุ
กลายเป็นสมาชิกชั้นหนึ่งของโมเดล

ข้อเสีย:

เพิ่มแรงเสียดทานติดตา (เช่น Entity Framework)
รหัสเพิ่มเติม

— ห้องเล็ก
แหล่งที่มา

คุณควรใช้คลาสที่กำหนดเองหรือไม่? แน่ใจ คุณควรใช้มันเป็นรหัส ไม่ใช่อย่างแน่นอน :) ID ที่มีความหมายทางธุรกิจจะทำให้เกิดปัญหาระหว่างทาง

— Songo

2

@Songo สำหรับฉันนั่นคืออาร์กิวเมนต์ที่ ID ควรมีsemantics ที่มีค่าแต่ประเภทดั้งเดิมไม่ใช่ประเภทเดียวที่มี semantics ตามค่าดังนั้นจึงไม่จำเป็นต้องแยกคลาส imo ออก รู้สึกอิสระที่จะโพสต์คำตอบการแข่งขัน แต่เนื่องจากฉันลืมที่จะทำให้จุด

— Ixrec

1

คำถามเก่า ๆ ของฉันเกี่ยวกับหัวข้อที่มีความคิดเห็นต่างกัน: programmers.stackexchange.com/questions/281827/ …ฉันไปกับการสร้างประเภทและดำเนินการต่อไป

— Ziv

6

หากคุณสามารถให้ฟังก์ชันที่มีประโยชน์กับคลาสเพียงพอที่จะพิสูจน์ความซับซ้อนที่เพิ่มขึ้นของการไม่ใช้สตริงให้ทำเช่นนั้น สำหรับตัวระบุเช่น ISBN และ ISIN ฉันสงสัยว่านี่ไม่ใช่กรณี

เพื่อให้คลาสตัวระบุมีประโยชน์ฉันคาดว่าจะมีลักษณะดังนี้

class ISIN {
    fromCUSIP()
    fromRawISINString()
    toString(ISIN::FormatType)
    getExchange()
    getCountryCode()
    getLastFourDigits()
    getWhateverCode()
    ...
}

หากมีลักษณะเช่นนี้แทน:

class ISIN {
    getString()
    setString()
}

จากนั้นฉันจะให้ชั้นเรียนทั้งหมดใช้สตริงปกติทุกที่และตรวจสอบให้แน่ใจว่าฉันใช้ "isin" อย่างสม่ำเสมอในชื่อตัวแปรที่เกี่ยวข้องทั้งหมด

โปรดทราบว่าในบางภาษาการเพิ่มประเภทใหม่นั้นแทบจะไม่มี "เพิ่มความซับซ้อน" ในโปรแกรมทั่วไปซึ่งในกรณีนี้คุณควรได้รับการสนับสนุนให้สร้างรูปแบบใหม่แม้ว่าจะไม่มีฟังก์ชั่นเลยก็ตาม แต่นี่ไม่ใช่กรณีสำหรับภาษา OOP แบบดั้งเดิมส่วนใหญ่เช่น C ++

— Ixrec
แหล่งที่มา

6

ฉันจะบอกว่าไปได้ ฉันจะยืนยันว่าข้อดีมีมากกว่าข้อเสียในกรณีนี้ รหัสพิเศษมีแนวโน้มที่จะค่อนข้างน้อยและปัญหาการคงอยู่ก็สามารถแก้ไขได้อย่างง่ายดายโดยให้แปลงบางอย่างระหว่างคลาสใหม่ของคุณและประเภทของฐานข้อมูลที่คาดหวัง (ฉันไม่เคยใช้ Entity Framework แต่ฉันรู้ว่านี่ค่อนข้างเจ็บปวด Hibernate)

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

book.setAuthor(otherBook.getAuthorName());
book.setIsbn(otherBook.getAuthorName());
book.setPrice(otherBook.getPrice())

หาก ISBN เป็นคลาสแทนที่จะเป็นประเภทดั้งเดิมดังนั้นโค้ดด้านบนจะไม่สามารถรวบรวมได้ทำให้ประหยัดเวลาในการดีบักในภายหลัง

— แมตต์วัตสัน
แหล่งที่มา

1

สุนัขเซทเทอร์และทะเยอทะยาน? มันคือ 1992

— เส้นทาง Miles