[java-list] API

Mon, 10 Dec 2001 16:30:23 -0800

Pessoal,
 
boa tarde.
Sou iniciante em Java e estou fazendo um trabalho para a Faculdade. Ser� que vcs poderiam me ajudar?
 
Quando criamos uma classe interna n�o-est�tica, h� a restri��o que todas as suas inst�ncias estar�o ligadas a uma containing instance da classe externa e ter�o acesso direto a seus atributos. Discuta as aplica��es de classes internas e por que elas s�o facilitadas pelos fatos acima.
Se uma classe C estende uma classe interna E.I mas n�o tenha rela��o com a externa E, a constru��o de C � complicada, afinal algu�m deve indicar a containing instance. A solu��o � deixar dispon�vel ao construtor de C uma inst�ncia e de E, seja via par�metro seja via atributo est�tico, e incluir como primeiro comando e.super (): 
class E {
  class I {
  }
}
class C extends E.I {
  // solucao via parametro
  public C (E e) {
    e.super ();
  }
}
class T {
  public static void main (String a []) {
    E e = new E ();
    C c = new C (e);
    System.exit (0);
  }
}
Pessoalmente, considero toda essa t�cnica e sua resolu��o um mal bem pouco necess�rio. O que vcs acham disso?.
 
Ana L�cia Pegetti
Analista de Tecnologia da Informa��o
Carbocloro Ind�strias Qu�micas S/A
TeL: 55 - 0XX13- 33613511 R:8268
 
 
 
-----Mensagem original-----
De: Rodrigo Miranda [mailto:[EMAIL PROTECTED]]
Enviada em: Segunda-feira, 10 de Dezembro de 2001 1:12
Para: [EMAIL PROTECTED]
Assunto: Re: [java-list] Sistemas gr�ficos

Coincidentemente j� implementei dois sistemas para cria��o de gr�ficos vetoriais. Em ambos nos deparamos com estes tipos de d�vidas.
Acho que n�o existe regra, pois tudo depende da flexibilidade da implementa��o, armazenamento, infra-estrutura, entre muitas outras vari�veis.
 
N�o vou entrar em detalhes da aplica��o.
No caso, n�o h� problema voc� fazer qualquer tipo de relacionamento - heran�a, composi��o, etc. Voc� n�o vai cair em um anti-padr�o com uma estrutura simples como esta.
 
No nosso caso implementamos uma outra esp�cie de especializa��o onde cont�vamos com objetos equi-redimension�veis ou n�o. No caso do quadrado, as al�as para redimensionar afetam toda a estrutura, enquanto o ret�ngulo tem eixos redimension�veis x e y.
Voc�  poderia criar uma classe "figura de 4 lados" com especializa��es para estes dois casos.... Assim o comportamento (behavior) � priorizado, e n�o a classifica��o por regras geom�tricas - o que pode ser melhor para um sistema. Mas depende da linha que voc�s est�o seguindo, requisitos, etc etc
 
[]'s
 
Rodrigo Miranda
 
----- Original Message -----
Sent: Thursday, December 06, 2001 5:41 PM
Subject: [java-list] Sistemas gr�ficos

Pessoal,
 
ser� que algu�m poderia me ajudar com esta quest�o?
 
Imagine que estamos projetando um sistema gr�fico capaz de armazenar, apresentar e alterar interativamente formas geom�tricas como elipses, ret�ngulos e segmentos de reta. Todas essas formas incluem um conjunto razo�vel de informa��es universais, como cor, posi��o e espessura de tra�o, portanto � razo�vel supor que objetos ofere�am vantagens na implementa��o (queremos facilmente definir c�digo capaz de desenhar, copiar, mover, salvar um conjunto arbitr�rio de formas, se poss�vel aceitando novas formas em futuras vers�es).
Considere os conceitos Ret�ngulo e Quadrado. Suponha que em nosso sistema ambos tenham suas dimens�es principais sempre alinhadas com os eixos cartesianos (em outras palavras, seriam poss�veis ret�ngulos "horizontais" e "verticais", nunca "diagonais"). Seria melhor Ret�ngulo estender Quadrado ou vice-versa? Ou n�o herdar? Quais  as vantagens e desvantagens de cada escolha sobre como implementar esses dois conceitos. Implemente uma delas brevemente em Java (esboce como ela seria usada).
 
Obrigada.
 
Ana L�cia Pegetti
Analista de Tecnologia da Informa��o
Carbocloro Ind�strias Qu�micas S/A
TeL: 55 - 0XX13- 33613511 R:8268
 

Responder a