Isso é uma classe bem criada?

Pode fazer assim:

Telefone(long Codigo, int DDD, int Numero, int Ramal, String Tipo) { this.Codigo=Codigo; this.DDD=DDD; this.Numero=Numero; this.Ramal=Ramal; this.Tipo=Tipo; }
Seria legal vc colocar public, private, etc…
Tá usando o eclipse? ele gera os get e sets pra vc automaticamente…
Aperte Ctrl + 3 e digite ggas que é a abreviação de Generate getters and setters e selecione todos os getters e setters.

Oi Danielly!
A sua classe não ta errada, como você mesma disse, ela compila normalmente. O que acontece é que está fora de alguns padrões usados, por exemplo: o nome das variáveis sempre começam com letra minuscula, não que seja obrigada a fazer assim, mas é uma forma de padronizar os códigos entre todos os programadores, entende? Então é legal usar.
Ja seus atributos, isso você vai dominando com o tempo, não se preocupe. Procure sempre analisar bem a necessidade de cada um.
O que eu acho que você deveria fazer era colocar os seus métodos gets e sets com o modificador de acesso public. Já que são métodos de acesso aos atributos, não acha que seria melhor eles serem acessados por outras classes? E também existem alguns especificações, como por exemplo os JavaBeans, onde é necessário declara-los assim, mas não vem ao caso falar disso. Você vai estudando, e com o tempo e vai entender tudo direitinho! Certo?
Acho que mandou bem na sua classe… qualquer dúvida posta ai tah??

Não sei ao certo mas eu já ouvi muito falar disso que passar atributos pelo construtor de classes que representam objetos reais não é uma boa pratica. Então fica ai uma dica. =D

daniellybifaratte:

Oi sou nova no GUJ e na área de programação. O professor explicou em sala de aula maneiras de se criar uma classe.
Segui as explicações de OO para fazer uma classe que represente um telefone… ficou assim

class Telefone {
   
      private long Codigo;
      private int DDD;
      private int Numero;
      private int Ramal;
      private String Tipo;
   
       Telefone(long Codigo, int DDD, int Numero, int Ramal, String Tipo) {
         this.setCodigo(Codigo);
         this.setDDD(DDD);
         this.setNumero(Numero);
         this.setRamal(Ramal);
         this.setTipo(Tipo);
      }
   	
       long getCodigo() { 
         return Codigo; }
       void setCodigo(long Codigo) { this.Codigo = Codigo; }
       int getDDD() { 
         return DDD; }
       void setDDD(int DDD) { this.DDD = DDD; }
       int getNumero() { 
         return Numero; }
       void setNumero(int Numero) { this.Numero = Numero; }
       int getRamal() { 
         return Ramal; }
       void setRamal(int Ramal) { this.Ramal = Ramal; }
       String getTipo() { 
         return Tipo; }
       void setTipo(String Tipo) { this.Tipo = Tipo; }
   }

mas alguns colegas disseram que está errado. A classe compila perfeitamente mas dizem que está fora do padrão de programação e que estou usando atributos desnecessários
Se alguém puder ajudar. Para mim está certa, obrigada.

É bom que os métodos set e get seja público.

1. Os métodos getters devem ser publicos.
2. Se a sua classe for ser uma classe imutável, os métodos getters devem ser private. Nesse caso, você pode usa-los no construtor. Se sua classe for mutável, então, deixe os métodos publicos e siga a dica do pedro. Ou então, torne sua classe ou esses métodos final.
3. Segundo a convenção do Java, os nomes dos atributos devem ter a primeira letra minúscula:

private  long codigo;  
private int ddd;  
private int numero;  
private int ramal;  
private String tipo;

public final void setCodigo(long codigo) { this.codigo = codigo; }

5. Seria bom também ajeitar a identação.

6. O construtor normalmente é public

7. A classe também deve ser declarada como public;

8. Verifique se o número do telefone será mesmo um int. Se for, sua classe não poderá conter números como "*222" ou "*222#"

9. O ideal seria que sua classe impedisse que o usuário entrasse com valores inválidos como valores negativos, ou o valor nulo para o tipo.

public final class Telefone {   
   private long codigo;
   private int ddd;
   private int numero;
   private int ramal;
   private String tipo;
   
   public Telefone(long codigo, int ddd, int numero, int ramal, String tipo) {
      this.setCodigo(codigo);  
      this.setDDD(ddd);  
      this.setNumero(numero);  
      this.setRamal(ramal);  
      this.setTipo(tipo);  
   }
   	
   public long getCodigo() { 
      return codigo; 
   }

   public void setCodigo(long Codigo) { 
      if (codigo < 0) {
         throw new IllegalArgumentException("O código do telefone deve ser maior que 0!");
      }
      this.codigo = codigo; 
   }

   public int getDDD() { 
      return ddd; 
   }

   public void setDDD(int ddd) { 
      if (codigo < 0) {
         throw new IllegalArgumentException("O código DDD deve ser maior que 0!");
      }

      this.ddd = ddd; 
   }

   public int getNumero() { 
      if (numero < 0) {
         throw new IllegalArgumentException("O número do telefone deve ser maior que 0!");
      }

      return numero; 
   }

   public void setNumero(int numero) { 
      this.numero = numero;
   }

   public int getRamal() { 
      return ramal; 
   }

   public void setRamal(int ramal) { 
      if (codigo < 0) {
         throw new IllegalArgumentException("O ramal deve ser maior ou igual a zero!");
      }

      this.ramal = ramal; 
   }

   public String getTipo() { 
      return tipo; 
   }

   public void setTipo(String tipo) { 
      this.tipo = tipo == null ? "" : tipo; 
   }
}

Obrigada pela ajuda de todos. Não conhecia essas dicas. :lol:

Outra pergunta: minha tela (tela.class) contém JLabels e JTextFields. Eles devem ser atributos da minha classe da tela? Ou podem ser criados dentro do método que constroe a tela e lá serem declarados (método mostrar())?

Geralmente precisam ser atributos, pois você precisará manipular esses objetos em outros métodos, além do construtor. Por exemplo, quando o usuário clicar num botão, será necessário ler o que foi digitado nas caixas de texto.
Você pode deixar só no construtor paineis e labels, que geralmente não serão manipulados em outros momentos do código.

Entendi Vini.

um código que não entendi lendo um artigo foi esse

public abstract class GUJ {
   public static interface Mensagem { }
}

sei que abstract significa que essa classe não poderá ser instanciada. Mas e essa interface aí dentro o que está fazendo??
não teria que ser uma classe separada?

O java permite que outras classes ou interfaces existam "dentro" de outra classe ou interface.

Nesse caso, você poderia instanciar implementar a interface assim:

//Implementa a interface Mensagem que existe dentro da classe GUJ
public class UmaClasse implements GUJ.Mensagem

Esse recurso é chamado de "inner class" ou "inner interface".

Existe também a diferença de uma Inner Class ser estática ou não. Uma inner class estática pode ser usada sem que haja uma instância da classe que a contém. Já a não estática não pode. Por outro lado, a não estática pode acessar os atributos da classe que a contém como se fossem seus.

public class Exemplo {
    private int x = 10;

    private class InnerExemplo {
        public void doSomething() {
            System.out.println(x); //Como InnerExemplo é interna e não estática, pode ver o x.
        }
    }

    public void imprimir() {
        new InnerExemplo().doSomething();
    }
}

Classes assim são úteis para quando uma classe só faz sentido no contexto de outra. Como é por exemplo o caso da classe No de uma Lista encadeada.

Entendi Viny. É errado ter um construtor sem argumentos?

Não.

Ouvi dizer q não se faz add() diretamente num JFrame.

janela.add() :x

e sim

janela.getContentPane().add()

Porque ñ pode se ambos funcionam?/

Não faz diferença, ambos os códigos são rigorosamente equivalentes.

No Java 1.3 ou inferior, não existia o .add diretamente. Mas agora que existe, não há motivos para não usa-lo.

:?: É correto acesar metodos como JTextField.getText() ou o certo é usar o Document do componente?

Mais outra: no seguinte caso…

JPanel p = new JPanel();
p.add(new JTextField(10));

:?: Como vou acessar o Document ou até mesmo o componente se não conheço a referência? (JTextField)

É correto sim. Geralmente, o código mais simples é o mais correto.

O Document você usa quando precisar controlar a inserção do texto no JTextField, no momento em que ela acontece.

Não vai. Guarde a referência. Até é possível chegar nesse JTextField através do painel (tem um método getComponents lá), mas você daria uma volta enorme para resolver, de maneira pouco eficiente, um problema que uma simples referência resolve.

É correto sim. Geralmente, o código mais simples é o mais correto.

O Document você usa quando precisar controlar a inserção do texto no JTextField, no momento em que ela acontece.

hummm… acho que isso é uma questão de gosto. Em tese vc não deveria usar os componentes diretamente da mesma forma que faria com um JTable ou um Jlist ; vc usa o model … em geral vc sempre usa o model, logo, no caso do texto não deveria ser diferente…

O problema é que, diferentemente das outras classes, implementar um Document não é assim tão trivial. Ele é usado também para editores de textos maiores, e acho que o esforço para uma caixinha tão pequena não é recompensado. Para isso, o document padrão, ou algum adaptado para ter limite máximo de caracteres já se adaptam muito bem.

Mas, certamente preferível implementar o document Diretamente se você for implementar um componente de textos grande e mais complexo, como um JEditorPane.

Bom na minha opniao acho que sim tou começando agora tambem , terminei ontem a aula de OO eu acho que ta bom . para quem ta começando agora .

legal.

Obrigada pelas respostas .

Classes que são interfaces devem ter o “i” identificador na frente do nome?
Assim: iCarro, iPredio, etc

Para completar: DAO ainda deve ser usado ou é coisa do recente passado?

daniellybifaratte:

Obrigada pelas respostas .

Classes que são interfaces devem ter o “i” identificador na frente do nome?
Assim: iCarro, iPredio, etc

Não. Pelo menos não na nomenclatura padrão.

O motivo é que uma interface deve ser indistinguível de uma classe (encapsulamento), se vc explicitamente declara uma interface com “i” vc mata o encapsulamento.

E sim , DAO é coisa do passado.

sergiotaborda:

daniellybifaratte:

Obrigada pelas respostas .

Classes que são interfaces devem ter o “i” identificador na frente do nome?
Assim: iCarro, iPredio, etc

Não. Pelo menos não na nomenclatura padrão.

O motivo é que uma interface deve ser indistinguível de uma classe (encapsulamento), se vc explicitamente declara uma interface com “i” vc mata o encapsulamento.

E sim , DAO é coisa do passado.

Sergio,

Nao entendi ainda o pq que a letra “I” em interfaces mata o encapsulamento. Poderia explicar?

el_loko:

sergiotaborda:

daniellybifaratte:

Obrigada pelas respostas .

Classes que são interfaces devem ter o “i” identificador na frente do nome?
Assim: iCarro, iPredio, etc

Não. Pelo menos não na nomenclatura padrão.

O motivo é que uma interface deve ser indistinguível de uma classe (encapsulamento), se vc explicitamente declara uma interface com “i” vc mata o encapsulamento.

E sim , DAO é coisa do passado.

Sergio,

Nao entendi ainda o pq que a letra “I” em interfaces mata o encapsulamento. Poderia explicar?

Entity carro = new Carro();

O que é Entity ? Interface, classe ou classe abstrata ?
Vc não sabe. E não tem como saber sem olhar o codigo fonte. Isso é encapsulamento.

Se eu colocar IEntity e definir que todas as interfaces começam com I, vc pode sempre dizer o que é interface e o que não é, e isso mata o encapsulamento.

No primeiro exemplo, se Entity era um interface e a transformei numa classe abstrata, nada muda, mas no segundo exemplo eu teria que sair tirando o I de todo o lugar. O ponto não é facilidade disso, (o eclipse faria num comando só) , o ponto é que vc violou o encapsulamento e é por isso que tem que alterar os nomes.

No .NET isso é uma nomenclatura comum por razões histórias, mas em java é completo non sense.

sergiotaborda:

Entity carro = new Carro();

O que é Entity ? Interface, classe ou classe abstrata ?
Vc não sabe. E não tem como saber sem olhar o codigo fonte. Isso é encapsulamento.

Se eu colocar IEntity e definir que todas as interfaces começam com I, vc pode sempre dizer o que é interface e o que não é, e isso mata o encapsulamento.

No primeiro exemplo, se Entity era um interface e a transformei numa classe abstrata, nada muda, mas no segundo exemplo eu teria que sair tirando o I de todo o lugar. O ponto não é facilidade disso, (o eclipse faria num comando só) , o ponto é que vc violou o encapsulamento e é por isso que tem que alterar os nomes.

No .NET isso é uma nomenclatura comum por razões histórias, mas em java é completo non sense.

Perguntei justamente pelo fato de ja ter visto a letra “I” em codigos C#. Vc sabe quais sao as razões histórias da microsoft para fazer isso?

Esse exemplo que vc citou seria realmente um problema, visto que alem de alterar o nome, seria necessario trocar a palavra implements por extends (nao sei se o eclipse faz tudo isso), mas de fato (do ponto de vista do encapsulamento), faz sentido nao usar o “I” para nomear interfaces.

el_loko:

sergiotaborda:

No .NET isso é uma nomenclatura comum por razões histórias, mas em java é completo non sense.

Perguntei justamente pelo fato de ja ter visto a letra “I” em codigos C#. Vc sabe quais sao as razões histórias da microsoft para fazer isso?

Básicamente a arquitetura COM que é baseada na notação hungara ( que é um lixo para OO , mas nos antigamentes era um must)

Mais sobre isso neste artigo do Fowler

Em java é uma coisa que nunca deve ser feita.

sergiotaborda:

Básicamente a arquitetura COM que é baseada na notação hungara ( que é um lixo para OO , mas nos antigamentes era um must)

Mais sobre isso neste artigo do Fowler

Em java é uma coisa que nunca deve ser feita.

Melhor referencia impossivel. Obrigado!

Dica: http://java.sun.com/docs/codeconv/

[]s

Obrigada pelas respostas,

mas uma classe abstrata, o que seria? Ela só pode ter métodos abstratos?
e como chamar uma classe abstrata?

:arrow: Não podemos criar uma instância de uma classe abstrata, mas ela pode ser derivada, ter “filhinhos e filhinhas”, rs.
:arrow: Classe abstrata pode ter métodos não abstratos, mas se você tiver um método que seja abstrato, esse não terá “corpo” e a sua definição deve ser completada em uma classe derivada.
:arrow: Se você definir um método como abstrato sua classe também deverá ser, mas repetindo: Você pode ter uma classe abstrata sem ter métodos abstratos se quiser…

Nossa, quanto “abstrato” na minha explicação. :shock:

Bom, se quiser saber mais: http://java.sun.com/docs/books/tutorial/java/IandI/abstract.html

Flw.