¿Constructor en una interfaz?

Sé que no es posible definir un constructor en una interfaz. Pero me pregunto por qué, porque creo que podría ser muy útil.

Entonces puede estar seguro de que algunos campos en una clase están definidos para cada implementación de esta interfaz.

Por ejemplo, considere la siguiente clase de mensaje:

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

Si defino una interfaz para esta clase para que pueda tener más clases que implementen la interfaz del mensaje, solo puedo definir el método de envío y no el constructor. Entonces, ¿cómo puedo asegurarme de que cada implementación de esta clase realmente tenga un conjunto de receptores? Si uso un método como setReceiver(String receiver) No puedo estar seguro de que este método realmente se llame. En el constructor pude asegurarlo.

Tomando algunas de las cosas que has descrito:

“Entonces puede estar seguro de que algunos campos en una clase están definidos para cada implementación de esta interfaz”.

“Si defino una interfaz para esta clase para que pueda tener más clases que implementen la interfaz del mensaje, solo puedo definir el método de envío y no el constructor”

…estos requisitos son exactamente lo que clases abstractas son para.

Un problema que surge cuando permite constructores en las interfaces proviene de la posibilidad de implementar varias interfaces al mismo tiempo. Cuando una clase implementa varias interfaces que definen diferentes constructores, la clase tendría que implementar varios constructores, cada uno de los cuales satisfaría solo una interfaz, pero no las demás. Será imposible construir un objeto que llame a cada uno de estos constructores.

O en código:

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

Una interfaz define un contrato para una API, que es un conjunto de métodos que acuerdan tanto el implementador como el usuario de la API. Una interfaz no tiene una implementación instanciada, por lo tanto, no tiene constructor.

El caso de uso que describe es similar a una clase abstracta en la que el constructor llama a un método de un método abstracto que se implementa en una clase secundaria.

El problema inherente aquí es que mientras se ejecuta el constructor base, el objeto secundario aún no se construye y, por lo tanto, se encuentra en un estado impredecible.

Para resumir: ¿está buscando problemas cuando llama a métodos sobrecargados de constructores principales, para citar menteprod:

En general, debe evitar llamar a métodos no finales en un constructor. El problema es que se realizan inicializadores de instancia/inicialización de variables en la clase derivada
después el constructor de la clase base.

Una solución alternativa que puede intentar es definir un getInstance() en su interfaz para que el implementador sepa qué parámetros deben manejarse. No es tan sólido como una clase abstracta, pero permite más flexibilidad al ser una interfaz.

Sin embargo, esta solución alternativa requiere que utilice el getInstance() para instanciar todos los objetos de esta interfaz.

P.ej

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

Solo hay campos estáticos en la interfaz que no necesitan inicializarse durante la creación del objeto en la subclase y el método de la interfaz debe proporcionar una implementación real en la subclase. Por lo tanto, no es necesario un constructor en la interfaz.

Segunda razón: durante la creación del objeto de la subclase, se llama al constructor principal. Pero si se implementará más de una interfaz, se producirá un conflicto durante la llamada del constructor de interfaz en cuanto a qué constructor de interfaz llamará primero.

Si desea asegurarse de que cada implementación de la interfaz contenga un campo específico, simplemente necesita agregar a su interfaz el getter para ese campo:

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

• no romperá la encapsulación
• hará saber a todos los que usan su interfaz que el Receiver el objeto debe pasarse a la clase de alguna manera (ya sea por el constructor o por el setter)

Las dependencias a las que no se hace referencia en los métodos de una interfaz deben considerarse detalles de implementación, no algo que la interfaz impone. Por supuesto, puede haber excepciones, pero como regla, debe definir su interfaz como se espera que sea el comportamiento. El estado interno de una implementación dada no debería ser una preocupación de diseño de la interfaz.