เหตุใดอินเทอร์เฟซจึงมีประโยชน์มากกว่าซูเปอร์คลาสในการรับคลัปหลวม

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

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

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

ตัวอย่างเช่นพิจารณาชั้นCarและสอง subclasses และVolvoMazda

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

นอกจากนี้Car- ซึ่งเป็นนามธรรม - มีโอกาสน้อยที่จะมีการเปลี่ยนแปลงกว่าหรือVolvo Mazdaโดยทั่วไปรถยนต์มักจะเหมือนกันมาระยะหนึ่งแล้ว แต่ Volvos และ Mazdas มีแนวโน้มที่จะเปลี่ยนไป I abstractions มีความเสถียรมากกว่าแบบคอนกรีต

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

สิ่งที่ฉันไม่เข้าใจคือ:

Abstractions สามารถเป็น superclasses หรืออินเทอร์เฟซ

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

ความแตกต่างเพียงอย่างเดียวที่ฉันเห็นคือ: 1 การเชื่อมต่อไม่ได้ถูก จำกัด ด้วยการถ่ายทอดทางพันธุกรรมเพียงอย่างเดียว แต่นั่นไม่ได้เกี่ยวข้องอะไรมากกับหัวข้อการมีเพศสัมพันธ์แบบหลวม ๆ 2- อินเทอร์เฟซเป็น 'นามธรรม' มากขึ้นเนื่องจากไม่มีตรรกะการใช้งานเลย แต่ถึงกระนั้นฉันไม่เห็นว่าทำไมที่สร้างความแตกต่างใหญ่

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

คำศัพท์: ฉันจะอ้างถึงการสร้างภาษาinterfaceเป็นอินเทอร์เฟซและอินเทอร์เฟซของชนิดหรือวัตถุเป็นพื้นผิว (สำหรับการขาดคำที่ดีกว่า)

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

แก้ไข.

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

ไม่ค่อยถูกต้องนัก ภาษาในปัจจุบันไม่คาดว่าจะมีการเปลี่ยนแปลง abstraction (แม้ว่าจะมีรูปแบบการออกแบบที่จะจัดการกับมัน) การแยกข้อมูลจำเพาะออกจากสิ่งทั่วไปคือสิ่งที่เป็นนามธรรม นี้มักจะทำโดยบางชั้นของนามธรรม เลเยอร์นี้สามารถเปลี่ยนเป็นข้อมูลจำเพาะอื่น ๆ ได้โดยไม่ต้องทำลายรหัสที่สร้างขึ้นบนสิ่งที่เป็นนามธรรมนี้ - การเชื่อมต่อแบบหลวม ๆ นั้นทำได้ ตัวอย่างที่ไม่ใช่ OOP: sortรูทีนอาจถูกเปลี่ยนจาก Quicksort ในเวอร์ชัน 1 เป็น Tim Sort ในเวอร์ชัน 2 โค้ดที่ขึ้นอยู่กับผลลัพธ์ที่เรียงลำดับเท่านั้น (เช่นการสร้างบนsortabstraction) จึงถูกแยกจากการใช้งานการเรียงลำดับจริง

สิ่งที่ฉันเรียกว่าพื้นผิวด้านบนคือส่วนทั่วไปของสิ่งที่เป็นนามธรรม ขณะนี้เกิดขึ้นใน OOP ว่าบางครั้งวัตถุหนึ่งต้องรองรับ abstractions หลายรายการ ตัวอย่างที่ไม่เหมาะสมที่สุด: Java java.util.LinkedListรองรับทั้งListอินเทอร์เฟซซึ่งเป็นเรื่องเกี่ยวกับสิ่งที่เป็นนามธรรม "ที่รวบรวมได้ซึ่งจัดทำดัชนีได้" และสนับสนุนQueueอินเทอร์เฟซที่ (ในแง่ที่หยาบ) เป็นเรื่องเกี่ยวกับสิ่งที่เป็นนามธรรม

วัตถุสามารถรองรับ abstractions หลายแบบได้อย่างไร

C ++ ไม่มีอินเตอร์เฟส แต่มันมีการสืบทอดหลายวิธีเสมือนและคลาสนามธรรม นามธรรมนั้นสามารถกำหนดเป็นคลาสนามธรรม (เช่นคลาสที่ไม่สามารถสร้างอินสแตนซ์ได้ทันที) ที่ประกาศ แต่ไม่กำหนดวิธีเสมือน คลาสที่ใช้งานเฉพาะของสิ่งที่เป็นนามธรรมนั้นสามารถสืบทอดจากคลาสนามธรรมนั้นและใช้วิธีเสมือนที่จำเป็น

ปัญหาในที่นี้คือการสืบทอดหลายอย่างสามารถนำไปสู่ปัญหาเพชรซึ่งลำดับที่ค้นหาคลาสสำหรับการใช้งานวิธี (MRO: ลำดับการแก้ไขเมธอด) สามารถนำไปสู่ ​​"ความขัดแย้ง" มีสองคำตอบสำหรับสิ่งนี้:

1. กำหนดคำสั่งที่มีสติและปฏิเสธคำสั่งที่ไม่สามารถทำให้เป็นเส้นตรงอย่างสมเหตุสมผล C3 MROเป็นธรรมสมเหตุสมผลและทำงานได้ดี ได้รับการตีพิมพ์ 2539

2. ใช้เส้นทางที่ง่ายและปฏิเสธการรับมรดกหลายรายการตลอด

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

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

สิ่งนี้กลับกลายเป็นสิ่งที่ไม่น่าพึงพอใจเพราะบ่อยครั้งที่พฤติกรรมบางอย่างเป็นส่วนหนึ่งของพื้นผิว พิจารณาComparableอินเทอร์เฟซ:

interface Comparable<T> {
    public int cmp(T that);
    public boolean lt(T that);  // less than
    public boolean le(T that);  // less than or equal
    public boolean eq(T that);  // equal
    public boolean ne(T that);  // not equal
    public boolean ge(T that);  // greater than or equal
    public boolean gt(T that);  // greater than
}

นี่เป็นมิตรกับผู้ใช้ (API ที่ดีและมีวิธีการที่สะดวกมากมาย) แต่น่าเบื่อที่จะใช้ เราต้องการให้อินเทอร์เฟซรวมเฉพาะcmpและใช้วิธีอื่นโดยอัตโนมัติในแง่ของวิธีการหนึ่งที่จำเป็น Mixinsแต่ที่สำคัญกว่านั้นคือลักษณะ [ 1 ], [ 2 ] แก้ปัญหานี้โดยไม่ตกหลุมพรางของมรดกหลายอย่าง

สิ่งนี้กระทำได้โดยการกำหนดองค์ประกอบของลักษณะเพื่อที่ว่าลักษณะจะไม่ได้มีส่วนร่วมใน MRO จริง ๆ แทนที่จะใช้วิธีการที่กำหนดไว้ในการใช้คลาสแทน

Comparableอินเตอร์เฟซที่อาจจะแสดงออกใน Scala เป็น

trait Comparable[T] {
    def cmp(that: T): Int
    def lt(that: T): Boolean = this.cmp(that) <  0
    def le(that: T): Boolean = this.cmp(that) <= 0
    ...
}

เมื่อคลาสใช้ลักษณะนั้นเมธอดอื่น ๆ จะถูกเพิ่มเข้ากับนิยามคลาส:

// "extends" isn't different from Java's "implements" in this case
case class Inty(val x: Int) extends Comparable[Inty] {
    override def cmp(that: Inty) = this.x - that.x
    // lt etc. get added automatically
}

ดังนั้นInty(4) cmp Inty(6)จะเป็น-2และจะเป็นInty(4) lt Inty(6)true

หลายภาษามีการสนับสนุนคุณสมบัติบางอย่างและภาษาใดก็ตามที่มี“ Metaobject Protocol (MOP)” สามารถเพิ่มคุณสมบัติได้ การอัพเดต Java 8 ล่าสุดเพิ่มเมธอดดีฟอลต์ซึ่งคล้ายกับลักษณะ (วิธีการในอินเตอร์เฟสสามารถมีการนำไปใช้ทางเลือกเพื่อให้เป็นทางเลือกสำหรับการใช้คลาสเพื่อใช้เมธอดเหล่านี้)

น่าเสียดายที่คุณลักษณะเป็นสิ่งประดิษฐ์ที่เพิ่งเกิดขึ้นค่อนข้างเร็ว (2002) และหาได้ยากในภาษากระแสหลักที่มีขนาดใหญ่กว่า

สิ่งที่ฉันไม่เข้าใจคือ:

Abstractions สามารถเป็น superclasses หรืออินเทอร์เฟซ

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

อย่างแรกการพิมพ์ย่อยและนามธรรมเป็นสองสิ่งที่แตกต่างกัน การพิมพ์ย่อยเพียงหมายความว่าฉันสามารถทดแทนค่าประเภทหนึ่งเป็นค่าประเภทอื่นได้ - ไม่จำเป็นต้องเป็นนามธรรม

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

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

มีการเชื่อมต่อระหว่างคลาสพาเรนต์กับเด็กเนื่องจากเด็กขึ้นอยู่กับพาเรนต์

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

สมมติว่าเรามีส่วนต่อประสาน I และคลาส B ใช้งานได้ หากเราเปลี่ยนอินเตอร์เฟส I แม้ว่าคลาส B อาจไม่ใช้อีกต่อไปคลาส B ก็จะไม่เปลี่ยนแปลง