Interfaces Delphi vs Interfaces Java

13/08/2013 at 22:34

Interfaces em Java são basicamente iguais as Interfaces em Delphi com uma pequena diferença. Em Delphi o correto é criar uma Interface, atribuí-la um GUID (ctrl+shift+g) e discriminar seus métodos e funções. Em seguida você pode criar uma Classe que implementa esta Interface e deve repetir todas as assinaturas definidas na Interface com o cuidado de definir a visibilidade de tais métodos e funções como não-públicos, dessa forma as variáveis sempre serão declaradas do tipo da Interface e o Delphi reconhecerá no code-completion e compilará normalmente. Em Java você não pode alterar a visibilidade dos métodos e funções definidas na Interface, que por padrão (caso a visibilidade seja omitida) é public, não precisa atribuir um GUID e deve atribuir o modificador @Override que no Delphi é desnecessário. Observe os códigos abaixo.

 

 

Em Delphi, assim como em qualquer outra linguagem OO as variáveis são sempre do tipo da Interface, observe que nesse caso não é necessário destruir o objeto, mesmo porque, não há método free ou destroy, já que TMyObject foi herdado de TInterfacedObject a própria VCL faz a contagem de referências e quando esta atingir zero destrói o objeto. Bem diferente do sofisticado Garbage Collection do Java.

O erro comum em Delphi é declarar a variável como TMyObject e os métodos como públicos, ferindo o princípio do encapsulamento e você pagará caro por isso ao chamar o método free que o Delphi autorizará em tempo de compilação mas causará erro em tempo de execução.

Se não é mais necessário controlar o ciclo de vida dos objetos em Delphi utilizando Interfaces, então é como em Java, você vai pro céu. Engano seu. Levando em consideração que a VCL faz a contagem de referências isso pode ser ainda pior. Você terá inúmeros objetos em memória desnecessariamente e com memory leak, pois você deve tomar o cuidado ao passar a referência desse objeto para outros objetos, pois se no parâmetro de entrada do objeto seguinte não houver a palavra-chave const a VCL incrementa a contagem de referências. Portanto você sempre terá que tomar conta do ciclo de vida dos objetos em Delphi.

Agora voltando ao assunto da visibilidade dos atributos (métodos e funções) das Interfaces Delphi vs Interfaces Java, para mim as de Java são melhores que as de Delphi, pois em Java o criador da Interface pode definir que a implementação da Interface deve ter o método getGreeting() com visibilidade private (pacote), por exemplo, pois já me deparei com essa necessidade várias vezes.

Visibilidades Delphi (de baixo para cima)

 

Java é Lento?

13/08/2013 at 00:24

Eis a dúvida cruel que persegue todo programador Delphi: “Java é lento porque é interpretado”.

As primeiras JVMs eram simplesmente interpretadores de bytecodes, liam arquivos .class e traduziam cada bytecode na sequência de execução para as instruções de máquina equivalentes. A partir do Java 1.1, a Sun incluiu seu primeiro JIT Compiler, adquirido da Symantec, e, no Java 1.2, incluiu o HotSpot. A evolução dessas duas tecnologias ao longo das versões do Java faz com que ele seja equiparável a aplicações nativas em C e C++.

Os grandes ganhos de performance do Java devem-se à otimização adaptativa, isto é, a capacidade de fazer otimizações de acordo com o uso do programa e as condições do ambiente. Tanto Java quanto C possuem uma etapa de compilação estática, que gera um arquivo binário a ser executado, e, durante essa compilação, várias otimizações são realizadas. A diferença é que o binário nativo C gerado é executado diretamente na máquina, e o binário Java é executado através da JVM, onde outras otimizações acontecem. No caso do C, toda otimização possível é feita estaticamente pelo compilador, enquanto que o Java consegue executar a segunda etapa de otimizações dentro da VM no momento da compilação dos bytecodes para código nativo, na chamada compilação dinâmica. É isto o que faz o Java executar tão rapidamente.