ตัวสร้างในอินเทอร์เฟซ

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

ดังนั้นคุณสามารถมั่นใจได้ว่ามีการกำหนดบางฟิลด์ในคลาสสำหรับทุกการใช้อินเทอร์เฟซนี้

ตัวอย่างเช่นพิจารณาคลาสข้อความต่อไปนี้:

public class MyMessage {

   public MyMessage(String receiver) {
      this.receiver = receiver;
   }

   private String receiver;

   public void send() {
      //some implementation for sending the mssage to the receiver
   }
}

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

รับบางสิ่งที่คุณอธิบายไว้:

"ดังนั้นคุณสามารถมั่นใจได้ว่ามีการกำหนดบางฟิลด์ในคลาสสำหรับการใช้อินเทอร์เฟซนี้ทุกครั้ง"

"หากการกำหนดส่วนต่อประสานสำหรับคลาสนี้เพื่อให้ฉันสามารถมีคลาสเพิ่มเติมซึ่งใช้ส่วนต่อประสานข้อความฉันสามารถกำหนดวิธีการส่งไม่ใช่ตัวสร้างเท่านั้น"

... ข้อกำหนดเหล่านี้เป็นสิ่งที่เป็นนามธรรมสำหรับชั้นเรียน

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

หรือในรหัส:

interface Named { Named(String name); }
interface HasList { HasList(List list); }

class A implements Named, HasList {

  /** implements Named constructor.
   * This constructor should not be used from outside, 
   * because List parameter is missing
   */
  public A(String name)  { 
    ...
  }

  /** implements HasList constructor.
   * This constructor should not be used from outside, 
   * because String parameter is missing
   */
  public A(List list) {
    ...
  }

  /** This is the constructor that we would actually 
   * need to satisfy both interfaces at the same time
   */ 
  public A(String name, List list) {
    this(name);
    // the next line is illegal; you can only call one other super constructor
    this(list); 
  }
}

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

กรณีการใช้งานที่คุณอธิบายนั้นคล้ายกับคลาสนามธรรมซึ่งนวกรรมิกเรียกใช้เมธอด abstract ซึ่งถูกนำไปใช้ในคลาสย่อย

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

เพื่อสรุป: มันคือการถามปัญหาเมื่อคุณเรียกใช้วิธีการมากเกินไปจากผู้สร้างผู้สร้างเพื่ออ้างmindprod :

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

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

อย่างไรก็ตามวิธีแก้ปัญหานี้ต้องการให้คุณใช้getInstance()อินสแตนซ์ของวัตถุทั้งหมดของอินเทอร์เฟซนี้

เช่น

public interface Module {
    Module getInstance(Receiver receiver);
}

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

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

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

interface IMyMessage(){
    @NonNull String getReceiver();
}

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

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

ดูคำถามนี้เพื่อหาสาเหตุ (นำมาจากความคิดเห็น)

หากคุณต้องการทำสิ่งนี้จริง ๆ คุณอาจต้องการคลาสฐานนามธรรมแทนอินเทอร์เฟซ

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

นี่คือตัวอย่างการใช้เทคนิคนี้ ในตัวอย่าง specifik นี้รหัสจะทำการเรียกไปยัง Firebase โดยใช้การเยาะเย้ยMyCompletionListenerที่เป็นอินเตอร์เฟซที่หลอกลวงเป็นคลาสนามธรรม, อินเตอร์เฟซที่มีการสร้าง

private interface Listener {
    void onComplete(databaseError, databaseReference);
}

public abstract class MyCompletionListener implements Listener{
    String id;
    String name;
    public MyCompletionListener(String id, String name) {
        this.id = id;
        this.name = name;
    }
}

private void removeUserPresenceOnCurrentItem() {
    mFirebase.removeValue(child("some_key"), new MyCompletionListener(UUID.randomUUID().toString(), "removeUserPresenceOnCurrentItem") {
        @Override
        public void onComplete(DatabaseError databaseError, DatabaseReference databaseReference) {

        }
    });
    }
}

@Override
public void removeValue(DatabaseReference ref, final MyCompletionListener var1) {
    CompletionListener cListener = new CompletionListener() {
                @Override
                public void onComplete(DatabaseError databaseError, DatabaseReference databaseReference) {
                    if (var1 != null){
                        System.out.println("Im back and my id is: " var1.is + " and my name is: " var1.name);
                        var1.onComplete(databaseError, databaseReference);
                    }
                }
            };
    ref.removeValue(cListener);
}

โดยทั่วไป Constructors สำหรับการเริ่มต้นสมาชิกที่ไม่คงที่ของคลาสเฉพาะด้วยความเคารพต่อวัตถุ

ไม่มีการสร้างวัตถุสำหรับส่วนต่อประสานเนื่องจากมีวิธีการประกาศเท่านั้น แต่ไม่ได้กำหนดวิธีการ ทำไมเราไม่สามารถสร้างวัตถุเพื่อประกาศวิธีการสร้างวัตถุคืออะไร แต่การจัดสรรหน่วยความจำบางส่วน (ในหน่วยความจำฮีป) สำหรับสมาชิกที่ไม่คงที่

JVM จะสร้างหน่วยความจำสำหรับสมาชิกที่ได้รับการพัฒนาอย่างเต็มที่และพร้อมใช้งานโดยขึ้นอยู่กับสมาชิกเหล่านั้น JVM จะคำนวณจำนวนหน่วยความจำที่ต้องการสำหรับพวกเขาและสร้างหน่วยความจำ

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

สรุป:

ไม่มีการสร้างวัตถุไม่มีโอกาสที่จะเริ่มต้นสมาชิกที่ไม่คงที่ผ่านตัวสร้างนั่นคือเหตุผลที่ว่าทำไมตัวสร้างไม่ได้รับอนุญาตภายในส่วนต่อประสาน (เนื่องจากไม่มีการใช้ตัวสร้างภายในส่วนต่อประสาน)