Konstruktor in einer Schnittstelle?

Ich weiß, dass es nicht möglich ist, einen Konstruktor in einer Schnittstelle zu definieren. Aber ich frage mich warum, weil ich denke, dass es sehr nützlich sein könnte.

Sie könnten also sicher sein, dass einige Felder in einer Klasse für jede Implementierung dieser Schnittstelle definiert sind.

Betrachten Sie beispielsweise die folgende Nachrichtenklasse:

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
   }
}

Wenn ich eine Schnittstelle für diese Klasse definiere, damit ich mehr Klassen haben kann, die die Nachrichtenschnittstelle implementieren, kann ich nur die Sendemethode und nicht den Konstruktor definieren. Wie kann ich also sicherstellen, dass jede Implementierung dieser Klasse wirklich einen Empfängersatz hat? Wenn ich eine Methode wie setReceiver(String receiver) Ich kann nicht sicher sein, ob diese Methode wirklich aufgerufen wird. Im Konstruktor konnte ich es sicherstellen.

Nehmen Sie einige der Dinge, die Sie beschrieben haben:

“So konnte man sicher sein, dass einige Felder in einer Klasse für jede Implementierung dieser Schnittstelle definiert sind.”

„Wenn ich eine Schnittstelle für diese Klasse definiere, damit ich mehr Klassen haben kann, die die Nachrichtenschnittstelle implementieren, kann ich nur die Sendemethode und nicht den Konstruktor definieren.“

…diese Anforderungen sind genau das Richtige abstrakte Klassen sind für.

Ein Problem, das Sie bekommen, wenn Sie Konstruktoren in Interfaces zulassen, ergibt sich aus der Möglichkeit, mehrere Interfaces gleichzeitig zu implementieren. Wenn eine Klasse mehrere Schnittstellen implementiert, die verschiedene Konstruktoren definieren, müsste die Klasse mehrere Konstruktoren implementieren, von denen jeder nur eine Schnittstelle erfüllt, aber nicht die anderen. Es wird unmöglich sein, ein Objekt zu konstruieren, das jeden dieser Konstruktoren aufruft.

Oder im Code:

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); 
  }
}

Eine Schnittstelle definiert einen Vertrag für eine API, d. h. eine Reihe von Methoden, auf die sich sowohl der Implementierer als auch der Benutzer der API einigen. Eine Schnittstelle hat keine instanzierte Implementierung, also keinen Konstruktor.

Der von Ihnen beschriebene Anwendungsfall ähnelt einer abstrakten Klasse, in der der Konstruktor eine Methode einer abstrakten Methode aufruft, die in einer untergeordneten Klasse implementiert ist.

Das inhärente Problem hierbei ist, dass während der Basiskonstruktor ausgeführt wird, das untergeordnete Objekt noch nicht konstruiert ist und sich daher in einem unvorhersehbaren Zustand befindet.

Zusammenfassend: Es ist problematisch, wenn Sie überladene Methoden von übergeordneten Konstruktoren aufrufen, um zu zitieren mindprod:

Im Allgemeinen müssen Sie es vermeiden, irgendwelche nicht-finalen Methoden in einem Konstruktor aufzurufen. Das Problem ist, dass Instanzinitialisierer / Variableninitialisierung in der abgeleiteten Klasse durchgeführt wird
nach der Konstruktor der Basisklasse.

Eine Problemumgehung, die Sie ausprobieren können, ist die Definition von a getInstance() -Methode in Ihrer Schnittstelle, damit der Implementierer weiß, welche Parameter behandelt werden müssen. Sie ist nicht so solide wie eine abstrakte Klasse, bietet aber mehr Flexibilität als eine Schnittstelle.

Diese Problemumgehung erfordert jedoch, dass Sie die verwenden getInstance() um alle Objekte dieser Schnittstelle zu instanziieren.

Z.B

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

Es gibt nur statische Felder in der Schnittstelle, die während der Objekterstellung in der Unterklasse nicht initialisiert werden müssen, und die Methode der Schnittstelle muss die tatsächliche Implementierung in der Unterklasse bereitstellen. Daher ist kein Konstruktor in der Schnittstelle erforderlich.

Zweiter Grund: Während der Objekterstellung der Unterklasse wird der übergeordnete Konstruktor aufgerufen. Wenn jedoch mehr als eine Schnittstelle implementiert wird, tritt beim Aufruf des Schnittstellenkonstruktors ein Konflikt darüber auf, welcher Schnittstellenkonstruktor zuerst aufgerufen wird

Wenn Sie sicherstellen möchten, dass jede Implementierung der Schnittstelle bestimmte Felder enthält, können Sie einfach müssen Sie Ihrer Schnittstelle den Getter für dieses Feld hinzufügen:

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

• Es wird die Kapselung nicht brechen
• Es wird allen, die Ihre Schnittstelle verwenden, mitteilen, dass die Receiver Objekt muss irgendwie an die Klasse übergeben werden (entweder per Konstruktor oder per Setter)

Abhängigkeiten, auf die nicht in Schnittstellenmethoden verwiesen wird, sollten als Implementierungsdetails betrachtet werden, nicht als etwas, das die Schnittstelle erzwingt. Natürlich kann es Ausnahmen geben, aber in der Regel sollten Sie Ihre Schnittstelle so definieren, wie das Verhalten erwartet wird. Der interne Zustand einer bestimmten Implementierung sollte kein Designproblem der Schnittstelle sein.