อะไรคือข้อเสียของการกำหนดคลาสเป็นคลาสย่อยของรายการของตัวเอง?

ในโครงการล่าสุดของฉันฉันกำหนดคลาสด้วยส่วนหัวต่อไปนี้:

public class Node extends ArrayList<Node> {
    ...
}

อย่างไรก็ตามหลังจากพูดคุยกับอาจารย์ประจำ CS ของฉันเขากล่าวว่าในชั้นเรียนจะ "น่ากลัวสำหรับความทรงจำ" และ "การปฏิบัติที่ไม่ดี" ฉันไม่ได้พบคนแรกที่เป็นจริงโดยเฉพาะและที่สองที่จะเป็นอัตนัย

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

ในทางกลับกันฉันเห็นว่านี่อาจเป็นการปฏิบัติที่ไม่ดี แนวคิดของการกำหนดสิ่งที่เป็นรายการของตัวเองนั้นไม่ง่ายหรือสามารถนำไปใช้งานได้จริง

มีเหตุผลที่ถูกต้องหรือไม่ทำไมฉันไม่ควรใช้รหัสนี้ในการพิจารณาการใช้งานของฉัน

¹หากฉันจำเป็นต้องอธิบายเรื่องนี้เพิ่มเติมฉันยินดีที่จะ; ฉันแค่พยายามทำให้คำถามนี้สั้นกระชับ

ตรงไปตรงมาฉันไม่เห็นความต้องการมรดกที่นี่ มันไม่สมเหตุสมผล Node เป็น ArrayListของNode?

หากนี่เป็นเพียงโครงสร้างข้อมูลแบบเรียกซ้ำคุณจะเขียนดังนี้:

public class Node {
    public String item;
    public List<Node> children;
}

ซึ่งจะทำให้ความรู้สึก; node มีรายการ children หรือโหนดที่สืบทอด

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

ตัวย่อ SOLID ให้การวิเคราะห์พฤติกรรมสำหรับการออกแบบเชิงวัตถุที่ดี ที่นี่I nterface Segregation Principle (ISP) และL iskov Substitution Pricinple (LSP) มีบางอย่างที่จะพูด

ISP บอกให้เรารักษาอินเตอร์เฟสให้เล็กที่สุดเท่าที่จะทำได้ แต่ด้วยการสืบทอดArrayListคุณจะได้รับวิธีการมากมาย มันมีความหมายกับget(), remove(), set()(แทนที่) หรือadd()(แทรก) โหนดเด็กที่ดัชนีโดยเฉพาะ? เป็นเรื่องที่สมเหตุสมผลensureCapacity()หรือไม่สำหรับรายการที่อยู่ภายใน? sort()โหนดหมายถึงอะไร? ผู้ใช้ในชั้นเรียนของคุณควรได้รับจริงsubList()หรือ เนื่องจากคุณไม่สามารถซ่อนเมธอดที่คุณไม่ต้องการได้ทางออกเดียวคือให้ ArrayList เป็นตัวแปรสมาชิกและส่งต่อเมธอดทั้งหมดที่คุณต้องการ:

private final ArrayList<Node> children = new ArrayList();
public void add(Node child) { children.add(child); }
public Iterator<Node> iterator() { return children.iterator(); }

หากคุณต้องการวิธีการทั้งหมดที่คุณเห็นในเอกสารเราสามารถไปยัง LSP LSP บอกเราว่าเราจะต้องสามารถใช้คลาสย่อยได้ในทุกที่ที่ผู้ปกครองต้องการ หากฟังก์ชั่นรับArrayListพารามิเตอร์เป็นและเราส่งผ่านNodeแทนไม่มีอะไรควรจะเปลี่ยน

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

แต่ LSP ทำงานได้ลึกกว่านี้มาก: เราต้องรักษาความเข้ากันได้กับทุกสิ่งที่สัญญาไว้ในเอกสารของคลาสแม่และอินเทอร์เฟซทั้งหมด ในคำตอบของพวกเขาลินน์พบกรณีหนึ่งกรณีที่Listอินเทอร์เฟซ (ซึ่งคุณสืบทอดมาArrayList) รับประกันว่าวิธีการequals()และhashCode()วิธีการทำงานอย่างไร สำหรับhashCode()คุณจะได้รับอัลกอริทึมเฉพาะที่ต้องดำเนินการอย่างแน่นอน สมมติว่าคุณเขียนสิ่งนี้Node:

public class Node extends ArrayList<Node> {
  public final int value;

  public Node(int value, Node... children) {
    this.value = Value;
    for (Node child : children)
      add(child);
  }

  ...

}

สิ่งนี้ต้องการให้สิ่งที่valueไม่สามารถมีส่วนร่วมhashCode()และไม่สามารถมีอิทธิพลequals()ได้ Listอินเตอร์เฟซ - ซึ่งคุณสัญญาว่าจะให้เกียรติโดยการสืบทอดจากมัน - ต้องการnew Node(0).equals(new Node(123))ที่จะเป็นจริง

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

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

ตัวอย่างหนึ่งคือปัญหาการสร้างแบบจำลองพนักงาน - หัวหน้า เรามีหลายรายการPersonแต่ละแห่งมีชื่อและที่อยู่ Employeeเป็นและมีPerson ยังเป็น ดังนั้นฉันควรสร้างคลาสที่สืบทอดและ? ตอนนี้ฉันมีปัญหา: เจ้านายก็เป็นพนักงานและก็มีหัวหน้าอีกคนหนึ่ง ดังนั้นจึงดูเหมือนว่าควรขยาย แต่เป็นแต่ไม่ได้เป็น? กราฟการสืบทอดประเภทใดจะแตกลงที่นี่BossBossPersonPersonBossEmployeeBossEmployeeCompanyOwnerBossEmployee

OOP ไม่เกี่ยวกับลำดับชั้นมรดกและกลับมาใช้ของชั้นเรียนที่มีอยู่มันเป็นเรื่องเกี่ยวgeneralizing พฤติกรรม OOP เป็นเรื่องเกี่ยวกับ“ ฉันมีวัตถุมากมายและต้องการให้พวกเขาทำสิ่งใดสิ่งหนึ่ง - และฉันไม่สนใจเลย” นั่นคืออินเทอร์เฟซสำหรับ หากคุณใช้Iterableอินเทอร์เฟซสำหรับของคุณNodeเพราะคุณต้องการทำให้ iterable นั่นเป็นเรื่องที่สมบูรณ์แบบ หากคุณติดตั้งCollectionส่วนต่อประสานเพราะคุณต้องการเพิ่ม / ลบโหนดลูกเป็นต้นนั่นก็ถือว่าใช้ได้ แต่สืบทอดมาจากคลาสอื่นเพราะมันเกิดขึ้นเพื่อให้คุณทั้งหมดที่ไม่ได้หรืออย่างน้อยไม่เว้นแต่คุณจะได้ให้มันคิดอย่างรอบคอบตามที่อธิบายไว้ข้างต้น

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

การเพิ่มสิ่งที่กล่าวมามีเหตุผลที่ค่อนข้างเฉพาะจาวาเพื่อหลีกเลี่ยงโครงสร้างประเภทนี้

สัญญาของequalsวิธีการสำหรับรายการต้องมีรายการที่จะพิจารณาเท่ากับวัตถุอื่น

และถ้าหากวัตถุที่ระบุยังเป็นรายการทั้งสองรายการมีขนาดเดียวกันและคู่ที่สอดคล้องกันทั้งหมดขององค์ประกอบในสองรายการมีความเท่าเทียมกัน

ที่มา: https://docs.oracle.com/javase/7/docs/api/java/util/List.html#equals(java.lang.Object)

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

เกี่ยวกับหน่วยความจำ:

ฉันจะบอกว่านี่เป็นเรื่องของลัทธิพอใจนิยม ตัวสร้างเริ่มต้นของArrayListมีลักษณะเช่นนี้:

public ArrayList(int initialCapacity) {
     super();

     if (initialCapacity < 0)
         throw new IllegalArgumentException("Illegal Capacity: "+ initialCapacity);

     this.elementData = new Object[initialCapacity];
 }

public ArrayList() {
     this(10);
}

แหล่ง คอนสตรัคนี้ยังใช้ใน Oracle-JDK

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

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

แก้ไข: คำชี้แจงเกี่ยวกับความคิดเห็น (@amon ให้แม่นยำ) คำตอบในส่วนนี้ไม่ได้เกี่ยวข้องกับปัญหาการสืบทอด การเปรียบเทียบการใช้หน่วยความจำนั้นทำขึ้นกับรายการที่เชื่อมโยงเดี่ยว ๆ และด้วยการใช้หน่วยความจำที่ดีที่สุด (ในการปรับใช้จริงปัจจัยอาจเปลี่ยนแปลงเล็กน้อย

เกี่ยวกับ "การปฏิบัติที่ไม่เหมาะสม":

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

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