Construtor em uma interface?

Eu sei que não é possível definir um construtor em uma interface. Mas estou me perguntando por que, porque acho que poderia ser muito útil.

Portanto, você pode ter certeza de que alguns campos de uma classe são definidos para todas as implementações dessa interface.

Por exemplo, considere a seguinte classe de mensagem:

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

Se definir uma interface para esta classe para que eu possa ter mais classes que implementam a interface da mensagem, só posso definir o método send e não o construtor. Então, como posso garantir que toda implementação dessa classe realmente tenha um receptor definido? Se eu usar um método como esse, setReceiver(String receiver)não posso ter certeza de que esse método seja realmente chamado. No construtor, eu poderia garantir isso.

Tomando algumas das coisas que você descreveu:

"Portanto, você pode ter certeza de que alguns campos de uma classe são definidos para todas as implementações dessa interface."

"Se um definir uma interface para esta classe para que eu possa ter mais classes que implementam a interface da mensagem, só posso definir o método send e não o construtor"

... esses requisitos são exatamente para que servem as classes abstratas .

Um problema que você obtém ao permitir construtores em interfaces vem da possibilidade de implementar várias interfaces ao mesmo tempo. Quando uma classe implementa várias interfaces que definem diferentes construtores, a classe precisa implementar vários construtores, cada um satisfazendo apenas uma interface, mas não os outros. Será impossível construir um objeto que chame cada um desses construtores.

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

Uma interface define um contrato para uma API, que é um conjunto de métodos com os quais o implementador e o usuário da API concordam. Uma interface não possui uma implementação instanciada, portanto, nenhum construtor.

O caso de uso que você descreve é ​​semelhante a uma classe abstrata na qual o construtor chama um método de um método abstrato que é implementado em uma classe filho.

O problema inerente aqui é que, enquanto o construtor de base está sendo executado, o objeto filho ainda não foi construído e, portanto, em um estado imprevisível.

Resumindo: é pedir problemas quando você chama métodos sobrecarregados de construtores-pai, para citar mindprod :

Em geral, você deve evitar chamar métodos não finais em um construtor. O problema é que inicializadores de instância / inicialização de variável na classe derivada são executados após o construtor da classe base.

Uma solução alternativa que você pode tentar é definir um getInstance()método em sua interface para que o implementador esteja ciente de quais parâmetros precisam ser manipulados. Não é tão sólido quanto uma classe abstrata, mas permite mais flexibilidade do que uma interface.

No entanto, esta solução alternativa exige que você use o getInstance()para instanciar todos os objetos dessa interface.

Por exemplo

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

Existem apenas campos estáticos na interface que não precisam ser inicializados durante a criação do objeto na subclasse e o método da interface deve fornecer implementação real na subclasse. Portanto, não há necessidade de construtor na interface.

Segunda razão: durante a criação do objeto da subclasse, o construtor pai é chamado. Mas, se houver mais de uma interface implementada, ocorrerá um conflito durante a chamada do construtor da interface sobre qual construtor da interface chamará primeiro

Se você deseja garantir que todas as implementações da interface contenham campos específicos, basta adicionar à sua interface o getter para esse campo :

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

• não vai quebrar o encapsulamento
• informará a todos que usam sua interface que o Receiverobjeto deve ser passado para a classe de alguma forma (por construtor ou setter)

Dependências que não são referenciadas nos métodos de uma interface devem ser consideradas como detalhes de implementação, não como algo que a interface impõe. É claro que pode haver exceções, mas, como regra, você deve definir sua interface como qual é o comportamento esperado. O estado interno de uma determinada implementação não deve ser uma preocupação de design da interface.

Veja esta pergunta para saber o porquê (retirado dos comentários).

Se você realmente precisar fazer algo assim, convém uma classe base abstrata em vez de uma interface.

Isso ocorre porque as interfaces não permitem definir o corpo do método nele. Mas devemos definir o construtor na mesma classe que as interfaces, por padrão, modificador abstrato para todos os métodos a serem definidos. É por isso que não podemos definir construtor nas interfaces.

Aqui está um exemplo usando esta técnica. Neste exemplo específico, o código está fazendo uma chamada para o Firebase usando uma simulação MyCompletionListenerque é uma interface mascarada como uma classe abstrata, uma interface com um construtor

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

Geralmente os construtores são para inicializar membros não estáticos de uma classe específica em relação ao objeto.

Não há criação de objeto para interface, pois existem apenas métodos declarados, mas não métodos definidos. O motivo pelo qual não podemos criar objetos para métodos declarados é que a criação de objetos nada mais é do que alocar memória (na memória heap) para membros não estáticos.

A JVM criará memória para membros totalmente desenvolvidos e prontos para uso. Com base nesses membros, a JVM calcula a quantidade de memória necessária para eles e cria memória.

No caso de métodos declarados, a JVM não consegue calcular a quantidade de memória necessária para esses métodos declarados, pois a implementação será no futuro, o que não será feito até o momento. portanto, a criação de objetos não é possível para a interface.

conclusão:

sem a criação do objeto, não há chance de inicializar membros não estáticos por meio de um construtor. É por isso que o construtor não é permitido dentro de uma interface. (como não há uso do construtor dentro de uma interface)