รายการอินเตอร์เฟสเป็นสิ่งที่เป็นนามธรรมหรือไม่?


9

ถ้าผมมีตัวแปรที่มีListมันอาจจะมีวัตถุจำนวนมากที่แตกต่างกันเช่นหรือArrayList LinkedListความแตกต่างระหว่าง a LinkedListและa ArrayListนั้นค่อนข้างใหญ่ พฤติกรรม O ใหญ่ของวิธีการนั้นแตกต่างกันอย่างมาก ยกตัวอย่างเช่นการเรียงลำดับListแล้วใช้มันเพื่อทำการค้นหาไบนารีเป็นอย่างดี ok สำหรับแต่จะไม่ทำให้รู้สึกด้วยArrayListLinkedList


"บิ๊กโอ" หมายความว่าอะไร?
Tulains Córdova

คำตอบ:


25

ฉันจะไม่พูดเช่นนั้น

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

หากมีการประกาศสิ่งที่Listไม่มีเอกสารเพิ่มเติมควรเข้าใจว่าไม่มีการรับประกันประสิทธิภาพการทำงานและหากคุณจะทำสิ่งใดก็ตามที่มีความอ่อนไหวต่อประสิทธิภาพคุณควรทำสำเนาและทำงานกับสิ่งนั้น

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


9
Iterableมีอินเตอร์เฟซที่แม้ทั่วไปมากขึ้นที่มักจะเพียงพอในการทำงานคือ
emory

ความแตกต่างของประสิทธิภาพระหว่างการใช้งานที่แตกต่างกันคาดว่า เช่นมีความแตกต่างระหว่าง Vector และ ArrayList แต่การดำเนินการ get บน LinkedList ดูเหมือนจะแปลก
Paling

17

abstractions ที่ไม่น่ารำคาญทั้งหมดในระดับหนึ่งมีการรั่วไหล ที่กล่าวว่าฉันไม่แน่ใจว่ามันใช้ที่นี่ :-)

บทคัดย่อเกี่ยวข้องกับพฤติกรรม ยกเว้นว่าพฤติกรรมดังกล่าวระบุถึงประสิทธิภาพเฉพาะ (ซึ่ง Java Listไม่มี) ก็เป็นรายละเอียดการนำไปใช้งาน - ไม่เกี่ยวข้อง

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

  1. จัดทำเอกสารไว้ในคลาส / อินเทอร์เฟซที่รายการอินสแตนซ์จะเป็นของ
  2. สร้างอินเทอร์เฟซใหม่ - เช่นBinarySearchPerformantList(yuck!) - ซึ่งระบุข้อกำหนดด้านประสิทธิภาพของวิธีการต่างๆ

ตัวเลือกที่ 2 น่าจะเป็นสิ่งที่ดีกว่านามธรรม แต่มาพร้อมกับค่าใช้จ่ายเพิ่มเติม


1
+1 ในทางเทคนิคใช่แล้วList คือสิ่งที่เป็นนามธรรมแต่แล้ว Object ก็คือการซ่อนความซับซ้อนที่เกี่ยวข้องกับการใช้equalsเพื่อเปรียบเทียบวัตถุ
Neil

2
@ ไม่มีฉันคิดว่ามันเป็นที่ถกเถียงกัน ... เนื่องจากสิ่งที่เป็นนามธรรมไม่ได้พูดถึงประสิทธิภาพฉันไม่คิดว่ามันจะล้มเหลวในกรณีนี้ ฉันจะบอกว่าถ้าคุณกำลังคิดเกี่ยวกับการแสดงคุณจะต้องมีนามธรรมที่แคบลง จะแก้ไขเพื่อพูดถึงว่า
vaughandroid

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

ผมเล่นรอบหลายปีที่ผ่านมาการดำเนินการรูปแบบของตัวเลือกที่ 2 โดยใช้อินเตอร์เฟซเครื่องหมายเหมือนLinearSpaceและแล้วประกาศเรียนเช่นLogarithmicTime public class BinarySearch : ISearchStrategy<T>, LogarithmicTimeคลาสอื่น ๆ อาจใช้พารามิเตอร์ที่ต้องการpublic T find<T, S>(IList<T> list, S strategy) where S : ISearchStrategy<T>, LogarithmicTime { }บังคับใช้ข้อ จำกัด ด้านประสิทธิภาพ
ลูคัส

2
ถ้าเราไปตามบทความ Joel Spolsky ฉันคิดว่ามันเป็น "ในระดับหนึ่งรั่ว" ดูคำพูดต่อไปนี้จากบทความ: "ถ้าคุณถูกสาปแช่งกับผู้ดูแลระบบใน บริษัท ของคุณและพวกเขาลงโทษคุณโดยการเสียบคุณเข้ากับฮับที่มีการโอเวอร์โหลดเฉพาะบางแพ็คเก็ต IP ของคุณเท่านั้นที่จะผ่านไปได้ จะช้ามาก "ฉันคิดว่านี่ใช้ได้
Amish Programmer

4

ใน Java มีส่วนต่อประสานRandomAccessซึ่งถูกกำหนดให้เป็นรายการที่มีเวลาเข้าถึงแบบสุ่มโดยทั่วไป (O (1) รับ, ใส่ ฯลฯ ) ถ้าคุณรู้สึกว่าโมดูลของคุณต้องมีรายการที่มีลักษณะการทำงานเหล่านั้นให้พิจารณาใช้แทนRandomAccess Listหากคุณไม่รู้สึกว่าจำเป็นต้องทำการเปลี่ยนแปลงนั้น (และมีน้อยคน) แสดงว่ารายการนั้นอาจไม่รั่วไหล


1

คุณถูกต้องรายชื่อเป็นสิ่งที่เป็นนามธรรม STL ใช้แนวคิดของแนวคิดเพื่อสร้างแบบจำลองปัญหาเฉพาะนี้ ที่จะใช้ตัวอย่างของคุณเป็นArrayListรุ่นRandom Access Iteratorขณะที่ LinkedList รุ่นForward Iterator แนวความคิดที่แตกต่างกันมีความต้องการประสิทธิภาพการทำงานที่แตกต่างกันซึ่งทำให้พวกเขาเหมาะสมสำหรับการที่แตกต่างกันขั้นตอนวิธีการ

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.