Re: Exceções, interfaces e Java

[PROTECTED]

"Sim, compila. De fato, a verificação estática de tipo dos objetos,
incluindo as possíveis exceções lançadas, foi um grande avanço (sempre
supondo que gostemos de linguagens fortemente tipadas...) e contribuiu
muito na qualidade do software."

Não deixa de ser um argumento válido, porém a importância da tipagem  forte
perde um pouco  a força a partir do momento que você tem unit tests que
cobrem todas (ou quase) as funcionalidades do sistema. Na verdade  ela se
torna dispensável.

[ ]'s




                                                                                                                                       
                      "Jorge F. Del                                                                                                    
                      Teglia"                  To:       PROTECTED                                                              
                      <PROTECTED        cc:       PROTECTED                                                           
                      .br>                     Subject:  Re: Exceções, interfaces e Java                                               
                                                                                                                                       
                      16/04/02 15:26                                                                                                   
                                                                                                                                       
                                                                                                                                       




Nelson, gostei muito dos seus comentários, mas não tanto assim alguns dos
de Alan...

><rant mode>
><Alan Durham mode>
>A questao aqui e' simples: Java, assim como C++, nao e' uma linguagem
>orientada a objetos "pura"; essas linguagem sacrificam parte de sua
>"pureza" em prol da checagem de tipos estrita em tempo de compilacao (o
>que, supostamente, evita erros) e em prol da performance.
>
>Em Smalltalk ("the one true OO-language"), um tipo e' definido por uma
>interface; ou seja, dois objetos que tem a mesma interface tem o mesmo
>tipo. Ponto. Final. Isso nao tem *nada* a ver com a arvore de hierarquias.


OOPS! Nada a ver?!?


>Uma classe define a *implementacao* de um tipo; uma classe B pode ser
>derivada da classe A, mas as duas podem *nao ser* do mesmo tipo.


Em particular, se B é subclasse de A, B *é* sub-tipo de A. Ponto. Final. ;
-)


>Por outro lado, duas classes que sao totalmente diferentes em termos de
>implementacao mas que tem a mesma interface tem o mesmo tipo. Ou seja,
>classes e tipos sao conceitos totalmente distintos: uma classe corresponde
>apenas `a implementacao de um tipo, e a heranca serve para reutilizar o
>codigo da implementacao de um tipo.
>
>Em Java e C++, a coisa e' diferente: para nao haver o "overhead" que ha'
>em smalltalk para "encontrar" um determinado metodo de um objeto qualquer,
>o endereco do metodo na memoria do processo tem que ser conhecido em tempo
>de compilacao; isso significa que nao e' possivel separar o tipo de sua
>implementacao, ou seja, da classe. Em Java e C++, dois objetos que tem
>exatamente a mesma interface so' sao do mesmo tipo se tambem pertencem a
>uma mesma hierarquia de classes.


Oops again!.
Não necessariamente é assim, como dito pelo mesmo Alan mais abaixo: se as
classes
dos respectivos objetos implementam a mesma interface (mesmo sem pertencer
a mesma hierarquia de classes), estes objetos *SÃO*  (pertencen/play),  do
tipo definido pela interface.


>Bom, e o que diabos isso tem a ver com as excecoes e essas regras
>"estranhas" que o Jorge falou? Muito simples: primeiro, e' bom lembrar que
>quando voce usa o "throws" voce esta' definindo um "contrato" entre voce
>(o desenvolvedor da classe) e o seu usuario (o usuario da sua classe),
>onde voce diz: "esta e' a lista de todas as excecoes que este metodo pode
>levantar". Voce faz isso para que o seu usuario possa escrever codigo
>capaz de lidar com essas excecoes. No fundo, voce esta' definindo mais
>"aspectos" da interface da sua classe e, portanto, do seu tipo.
>
>Agora, seja uma superclasse A e sua subclasse B. B e' do tipo de A e,
>portanto, B *precisa* poder interagir com outros objetos como se fosse um
>objeto da classe A. Mas se B gerasse uma excecao que A nao geraria, a
>coisa toda iria para o beleleu: voce poderia fazer um codigo lindo para
>lidar com objetos do tipo A e cuidar de todas as excecoes possiveis, mas
>esse codigo poderia falhar miseravelmente com um objeto da classe B. Como
>Java prioriza a checagem em tempo de compilacao, essa situacao "esdruxula"
>nao e' permitida pelo compilador: se isso fosse permitido, teriamos uma
>situacao tal que dois objetos dentro de uma mesma hierarquia nao teriam de
>fato a mesma interface (se considerarmos as excecoes como parte da
>"interface").

100% !

>Tenho a impressao que C++ e' mais "permissiva" nesse
>quesito; talvez gere uns "warnings", mas acho que o codigo compila, mas
>nao verifiquei.


Sim, compila. De fato, a verificação estática de tipo dos objetos,
incluindo as possíveis exceções lançadas, foi um grande avanço (sempre
supondo que gostemos de linguagens fortemente tipadas...) e contribuiu
muito na qualidade do software.


Abraços

Jorge