Delphi Array To Java Array

17/08/2013 at 18:32

Eis aqui enorme diferença entre as duas plataformas, pois em Java tudo é orientado a objeto nem que for através de métodos estáticos de uma classe base da API.

Array Dinâmico em Delphi

A linha 6 aloca quatro posições do tipo TMyOtherObject na memória para a variável “a” através da chamada ao método procedural setLength da unit system. A linha 7 atribui a nova instância de TMyOtherObject à posição zero do array. A linha 8 recupera aquela instância na variável “x”. A linha 9 escreve no console o conteúdo de TMyOtherObject.

 Array Dinâmico em Java

A linha 2 aloca quatro posições do tipo MyOtherObject na memória para a variável “a” através da chamada ao método estático newInstance da classe Array, é nele, no primeiro argumento que você indica o tipo do conteúdo do array e não na declaração da variável como no Delphi, e no segundo argumento o tamanho. A linha 3 atribui a nova instância de MyOtherObject à posição zero do array através da chamada ao método estático set da classe Array, cujo primeiro argumento é a variável do array, o segundo a posição, o terceiro é o objeto. A linha 4 recupera aquela instância na variável “x” através da chamada ao método estático get da classe Array, cujo primeiro argumento também é a variável do array e no segundo a posição. A linha 5 escreve no console o conteúdo de MyOtherObject.

 

 

 

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)