Java abstract interface

พิจารณาตัวอย่าง (ซึ่งคอมไพล์ใน java)

public abstract interface Interface {
    public void interfacing();
    public abstract boolean interfacing(boolean really);
}

ทำไมมันจำเป็นสำหรับอินเทอร์เฟซที่จะเป็นนามธรรม "ประกาศ"? มีกฎอื่น ๆ ที่ใช้กับอินเทอร์เฟซแบบนามธรรมหรือไม่?

ในที่สุด: หากabstractล้าสมัยแล้วทำไมจึงรวมอยู่ใน Java มีประวัติสำหรับส่วนต่อประสานนามธรรมหรือไม่?

ทำไมมันจำเป็นสำหรับอินเทอร์เฟซที่จะเป็นนามธรรม "ประกาศ"?

มันไม่ใช่.

public abstract interface Interface {
       \___.__/
           |
           '----> Neither this...

    public void interfacing();
    public abstract boolean interfacing(boolean really);
           \___.__/
               |
               '----> nor this, are necessary.
}

อินเทอร์เฟซและวิธีการของพวกเขาโดยปริยายabstractและเพิ่มที่ปรับปรุงทำให้ไม่มีความแตกต่าง

มีกฎอื่น ๆ ที่ใช้กับอินเทอร์เฟซแบบนามธรรมหรือไม่?

ไม่ใช้กฎเดียวกัน วิธีการจะต้องดำเนินการโดยการใช้งานชั้นใด ๆ (เป็นรูปธรรม)

หากนามธรรมล้าสมัยแล้วทำไมมันจึงรวมอยู่ใน Java? มีประวัติสำหรับส่วนต่อประสานนามธรรมหรือไม่?

คำถามที่น่าสนใจ ฉันขุดขึ้นครั้งแรกฉบับ JLS และยังมีที่จะกล่าวว่า"การแก้ไขนี้จะล้าสมัยและไม่ควรนำมาใช้ในโปรแกรม Java ใหม่"

โอเคขุดต่อไป ... หลังจากกดลิงค์ที่เสียหายหลายครั้งฉันก็สามารถหาข้อมูลจำเพาะของOak 0.2 ดั้งเดิม(หรือ "คู่มือ") ได้ อ่านค่อนข้างน่าสนใจฉันต้องพูดและมีเพียง 38 หน้ารวม! :-)

ภายใต้ส่วนที่ 5 อินเทอร์เฟซจะแสดงตัวอย่างต่อไปนี้:

public interface Storing {
    void freezeDry(Stream s) = 0;
    void reconstitute(Stream s) = 0;
}

และในระยะขอบมันบอกว่า

ในอนาคตส่วน "= 0" ของวิธีการประกาศในอินเทอร์เฟซอาจหายไป

สมมติว่า=0มีการแทนที่ด้วยabstractคำหลักฉันสงสัยว่าabstractเป็นบางจุดบังคับสำหรับวิธีการอินเตอร์เฟส!

บทความที่เกี่ยวข้อง: Java: อินเตอร์เฟซที่เป็นนามธรรมและวิธีการอินเตอร์เฟซที่เป็นนามธรรม

มันไม่จำเป็นมันเป็นทางเลือกเช่นเดียวpublicกับวิธีการอินเทอร์เฟซ

ดู JLS เกี่ยวกับเรื่องนี้:

http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html

9.1.1.1 การเชื่อมต่อที่เป็นนามธรรมทุกอินเตอร์เฟสจะเป็นนามธรรมโดยปริยาย โมดิฟายเออร์นี้ล้าสมัยและไม่ควรใช้ในโปรแกรมใหม่

และ

9.4 การประกาศวิธีการที่เป็นนามธรรม

[ ... ]

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

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

ไม่จำเป็นต้องประกาศ abstract ของอินเตอร์เฟส

เช่นเดียวกับการประกาศวิธีการทั้งหมดที่เป็นสาธารณะ (ซึ่งเป็นที่เรียบร้อยแล้วหากส่วนต่อประสานเป็นแบบสาธารณะ) หรือเป็นนามธรรม (ซึ่งมีอยู่แล้วในส่วนต่อประสาน) นั้นซ้ำซ้อน

ไม่มีใครหยุดคุณได้

สิ่งอื่น ๆ ที่คุณสามารถระบุได้อย่างชัดเจน แต่ไม่จำเป็นต้อง:

• เรียก super () ที่บรรทัดแรกของตัวสร้าง
• extends Object
• ใช้อินเตอร์เฟสที่สืบทอดมา

มีกฎอื่น ๆ ที่ใช้กับอินเทอร์เฟซแบบนามธรรมหรือไม่?

อินเทอร์เฟซเป็น "นามธรรม" อยู่แล้ว การใช้คำหลักนั้นอีกครั้งทำให้ไม่แตกต่างอย่างแน่นอน

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

ตัวอย่างจริง: พร็อกซี่ @Service ภายใต้ @Transnational เพื่อความจำเป็น @Repository จะใช้วิธีการพื้นฐานที่เหมือนกัน @Autowiredแต่พวกเขาควรจะใช้อินเตอร์เฟซที่แตกต่างกันที่ขยายอินเตอร์เฟซที่เป็นนามธรรมนี้เนื่องจาก (ฉันเรียกอินเตอร์เฟซ XXXSpec นี้)

ทุกอินเตอร์เฟสนั้นเป็นนามธรรมโดยปริยาย
โมดิฟายเออร์นี้ล้าสมัยและไม่ควรใช้ในโปรแกรมใหม่

[ข้อกำหนดภาษา Java - การabstractเชื่อมต่อ9.1.1.1 ]

public abstractนอกจากนี้ยังทราบว่าวิธีการอินเตอร์เฟซเป็นสมาชิกโดยปริยาย
[ข้อกำหนดภาษา Java - สมาชิกส่วนต่อประสาน 9.2]

เหตุใดตัวดัดแปลงเหล่านี้จึงมีความหมายโดยนัย? ไม่มีโมดิฟายเออร์อื่น ๆ (ไม่ใช่แม้แต่ 'โมดิฟายเออร์' - โมดิฟายเออร์) ที่จะมีประโยชน์ที่นี่ดังนั้นคุณไม่จำเป็นต้องพิมพ์

มันไม่จำเป็น มันเป็นเรื่องแปลกของภาษา

ไม่จำเป็นเนื่องจากส่วนต่อประสานเป็นนามธรรมเริ่มต้นเนื่องจากวิธีการทั้งหมดในส่วนต่อประสานเป็นนามธรรม

อินเทอร์เฟซที่เป็นนามธรรมไม่ซ้ำซ้อนอย่างที่ทุกคนดูเหมือนจะพูด

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

ตัวอย่าง:

public abstract interface MyBaseInterface {
    public String getName();
}

public interface MyBoat extends MyBaseInterface {
    public String getMastSize();
}

public interface MyDog extends MyBaseInterface {
    public long tinsOfFoodPerDay();
}

คุณไม่ต้องการให้คลาสใช้งาน MyBaseInterface เฉพาะอีกสอง MMyDog และ MyBoat แต่อินเทอร์เฟซทั้งสองใช้อินเทอร์เฟซ MyBaseInterface ร่วมกันดังนั้นมีคุณสมบัติ 'ชื่อ'

ฉันรู้ว่ามันเป็นวิชาการ แต่ฉันคิดว่าบางคนอาจคิดว่ามันน่าสนใจ :-)

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

ดี 'บทคัดย่ออินเตอร์เฟซ' เป็นสร้างคำศัพท์: http://en.wikipedia.org/wiki/Lexical_analysis

interfaceมันถูกต้องตามคอมไพเลอร์ที่คุณยังสามารถเขียน

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

สาระสำคัญของ `ส่วนต่อประสานคือการรวบรวมแนวคิดที่เป็นนามธรรม (ความคิด / ความคิด / ความคิดลำดับสูงขึ้น ฯลฯ ) ซึ่งการนำไปปฏิบัติอาจแตกต่างกันไป ... นั่นคืออาจมีการนำไปใช้หลายอย่าง

อินเทอร์เฟซเป็นชนิดข้อมูลนามธรรมที่แสดงถึงคุณลักษณะของวัตถุที่จับหรือแสดง

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

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

คลาสที่เป็นรูปธรรมจะเป็นคลาส / ชุดของคลาสที่จะจับภาพนามธรรมที่คุณพยายามจับคลาส XYZ อย่างเต็มที่

ดังนั้นรูปแบบคือ

Interface--->Abstract class/Abstract classes(depends)-->Concrete class