Implicity Interface

12 de junho de 2008 6 respostas

peczenyj 12 de junho de 2008

Esse código fala por si so:

interface I{
        void doIt();
}
interface J{
        void doIt();
}

class X implements I{
        public void doIt(){ 
            System.out.println("oi");
        }
}
public class A {
    public static void go(I arg){ arg.doIt();  }
    public static void go(J arg){ arg.doIt();  }
    public static void main (String [] args){
        X x = new X();
        go(x);
    }
}

go(x) vai chamar o método estático go(I arg), afinal a classe X implementa a interface I.

Agora a interface J é identica a I, o que impede que a classe X se comporte como J, ao menos em tempo de compilação? Isso seria mais custoso para o compilador ou poderia induzir a erros de modelagem/runtime/etc?

Afinal uma interface é um contrato, se o meu objeto respeita esse contrato...

6 Respostas

thingol 12 de jun. de 2008

Você quer “duck typing” (ou seja, se anda como um pato, nada como um pato, grasna como um pato, então é um pato?)

O problema é que é difícil para a JVM (não exatamente para o compilador) investigar se 2 interfaces são idênticas, para o que você quer.

sergiotaborda 12 de jun. de 2008

peczenyj:

Agora a interface J é identica a I, o que impede que a classe X se comporte como J, ao menos em tempo de compilação? Isso seria mais custoso para o compilador ou poderia induzir a erros de modelagem/runtime/etc?

Afinal uma interface é um contrato, se o meu objeto respeita esse contrato…

Vc está pensando que o contrato é apenas o conjunto dos métodos e suas assinaturas. Não é.
O contrato começa com o proprio tipo de interface.

Pense em Serializable por exemplo, que não tem métodos. A classe da interface é o contrato.

além da classe e métodos o contrato pode se extender ao que os métodos fazem. Como devem reagir etc.
Coisas que não são colocadas explciitamente na nterface. Por exemplo, Comparable , confronte o contrato dele com o de equals()
Se passar null em equals simplesmente retorna false, mas em Comparable deve lançar ClassCastException. Isso não tem como colocar no codigo da interface. So da implementação.

Por outro lado se A tem a mesma interface que B vc pode facilmente criar proxies que transformem um no outro. A classe Proxy faz isso bem facilmente.

peczenyj 12 de jun. de 2008

É… pensei em duck typing.

Sem falar que nem precisariam ser interfaces identicas, bastaria ver se a classe X implementa tudo o que a interface requerida implementa.

Por um lado ONERA bastante a JVM, mas não compreendo se existe alguma outra impossibilidade de descobrir isso em runtime que esteja entranhado ao bytecode, etc.

thingol 12 de jun. de 2008

Acho que no JDk 7 você vai poder (não usando Java, é claro, mas outra linguagem qualquer) ter suporte a duck typing e outras coisas mais escabrosas (com aquele novo bytecode “invokedynamic”).

urubatan 12 de jun. de 2008

Ja que tu quer uma linguagem dinamica, programe em uma linguagem dinâmica.
É muito dificil, até mesmo quase impossível pelo motivo citado pelo sergiotaborda, implementar duck typing em uma linguagem estaticamente tipada.
mas tu pode simplesmente utilizar Groovy na JVM, a sitnaxe é muito parecida com Java, mas tu pode trabalhar com tipagem dinâmica e ter duck typing …

peczenyj 12 de jun. de 2008

Sem graça

Criado 12 de junho de 2008

Ultima resposta 12 de jun. de 2008

Respostas 6

Participantes 4

6 Respostas

Topicos relacionados