การสืบทอด vs คุณสมบัติเพิ่มเติมที่มีค่า Null

สำหรับคลาสที่มีฟิลด์เป็นตัวเลือกจะดีกว่าถ้าใช้การสืบทอดหรือคุณสมบัติที่เป็นโมฆะ? ลองพิจารณาตัวอย่างนี้:

class Book {
    private String name;
}
class BookWithColor extends Book {
    private String color;
}

หรือ

class Book {
    private String name;
    private String color; 
    //when this is null then it is "Book" otherwise "BookWithColor"
}

หรือ

class Book {
    private String name;
    private Optional<String> color;
    //when isPresent() is false it is "Book" otherwise "BookWithColor"
}

รหัสขึ้นอยู่กับ 3 ตัวเลือกเหล่านี้จะเป็น:

if (book instanceof BookWithColor) { ((BookWithColor)book).getColor(); }

หรือ

if (book.getColor() != null) { book.getColor(); }

หรือ

if (book.getColor().isPresent()) { book.getColor(); }

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

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

แต่โดยทั่วไปคุณสมบัติที่เหมาะสมสำหรับคลาสย่อยบางอย่างควรมีอยู่ในคลาสย่อยเหล่านั้นเท่านั้น

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

ตัวอย่างที่ดีกว่าคือการดูคลาสจากซอฟต์แวร์จริง องค์ประกอบมีสนามJSlider majorTickSpacingเนื่องจากแถบเลื่อนมี "เห็บ" ฟิลด์นี้จึงเหมาะสมสำหรับJSliderและผู้สืบทอดเท่านั้น มันจะสับสนมากถ้าส่วนประกอบอื่น ๆ ของพี่น้องเช่นJButtonมีmajorTickSpacingสนาม

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

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

คิดว่า JavaBean (เหมือนของคุณBook) เป็นบันทึกในฐานข้อมูล คอลัมน์ตัวเลือกคือnullเมื่อไม่มีค่า แต่เป็นกฎหมายที่สมบูรณ์ ดังนั้นตัวเลือกที่สองของคุณ:

class Book {
    private String name;
    private String color; // null when not applicable
}

มีความสมเหตุสมผลที่สุด ¹

ระวังด้วยวิธีการใช้Optionalคลาส ตัวอย่างเช่นไม่ใช่Serializableซึ่งโดยปกติจะเป็นลักษณะของ JavaBean นี่คือเคล็ดลับบางส่วนจากStephen Colebourne :

1. ไม่ได้ประกาศตัวแปรเช่นใด ๆ Optionalของประเภท
2. ใช้nullเพื่อระบุข้อมูลเพิ่มเติมภายในขอบเขตส่วนตัวของคลาส
3. ใช้Optionalสำหรับ getters ที่เข้าถึงฟิลด์ตัวเลือก
4. ห้ามใช้Optionalใน setters หรือ constructors
5. ใช้Optionalเป็นชนิดส่งคืนสินค้าสำหรับวิธีการตรรกะทางธุรกิจอื่น ๆ ที่มีผลลัพธ์เป็นตัวเลือก

ดังนั้นภายในชั้นเรียนของคุณคุณควรจะใช้nullเพื่อเป็นตัวแทนว่าสนามไม่อยู่ แต่เมื่อcolor ใบBook (เป็นประเภทผลตอบแทน) Optionalมันควรจะห่อกับ

return Optional.ofNullable(color); // inside the class

book.getColor().orElse("No color"); // outside the class

นี้ให้การออกแบบที่ชัดเจนและอ่านง่ายขึ้น

¹ถ้าคุณตั้งใจสำหรับBookWithColorการ encapsulate เป็น "ระดับ" ทั้งหนังสือที่มีความเชี่ยวชาญความสามารถมากกว่าหนังสือเล่มอื่น ๆแล้วมันจะทำให้รู้สึกถึงการใช้งานมรดก

คุณควรใช้อินเตอร์เฟส (ไม่ใช่การสืบทอด) หรือกลไกคุณสมบัติบางอย่าง (อาจเป็นบางสิ่งที่ทำงานได้เหมือนกรอบคำอธิบายทรัพยากร)

ดังนั้นทั้ง

interface Colored {
  Color getColor();
}
class ColoredBook extends Book implements Colored {
  ...
}

หรือ

class PropertiesHolder {
  <T> extends Property<?>> Optional<T> getProperty( Class<T> propertyClass ) { ... }
  <V, T extends Property<V>> Optional<V> getPropertyValue( Class<T> propertyClass ) { ... }
}
interface Property<T> {
  String getName();
  T getValue();
}
class ColorProperty implements Property<Color> {
  public Color getValue() { ... }
  public String getName() { return "color"; }
}
class Book extends PropertiesHolder {
}

การชี้แจง (แก้ไข):

เพียงเพิ่มฟิลด์ตัวเลือกในคลาสเอนทิตี

โดยเฉพาะอย่างยิ่งกับ Wrapper ที่เป็นตัวเลือก (แก้ไข: ดูคำตอบของ4castle ) ฉันคิดว่านี่ (การเพิ่มเขตข้อมูลในเอนทิตีดั้งเดิม) เป็นวิธีที่ทำงานได้เพื่อเพิ่มคุณสมบัติใหม่ในขนาดเล็ก ปัญหาที่ใหญ่ที่สุดด้วยวิธีนี้คือมันอาจทำงานกับการมีเพศสัมพันธ์ต่ำ

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

เหตุใดการสืบทอดจึงเป็นปัญหาเมื่อหาวิธีให้คุณสมบัติเพิ่มเติม

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

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

อ่านเพิ่มเติมว่าทำไมการสืบทอดมักเป็นแนวคิดที่มีปัญหา:

เหตุใดโดยทั่วไปการรับมรดกจึงมองว่าเป็นสิ่งเลวร้ายโดยผู้เสนอ OOP

JavaWorld: ทำไมการขยายความชั่วร้าย

ปัญหาเกี่ยวกับการนำชุดอินเตอร์เฟสไปใช้เพื่อสร้างชุดของคุณสมบัติ

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

แก้ไข: อีกด้านที่สำคัญคือการกล่าวถึงโดยgnasher729 คุณมักจะต้องการเพิ่มคุณสมบัติทางเลือกให้กับวัตถุที่มีอยู่แบบไดนามิก ด้วยการสืบทอดหรืออินเทอร์เฟซคุณจะต้องสร้างวัตถุทั้งหมดด้วยคลาสอื่นซึ่งอยู่ห่างจากทางเลือก

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

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

ถ้าBookคลาสสามารถดำเนินการได้โดยไม่มีคุณสมบัติสีดังนี้

class E_Book extends Book{
   private String type;
}

การรับมรดกนั้นสมเหตุสมผล