Classes Abstratas

Na verdade seriam beans… que herdam da classe mãe…não classes abstratas…

public class Cliente{

private String nome;

public void setNome(String nome){
 this.nome = nome;
}
public String getNome(){
return this.nome;
}
//depois adiciona o restante dos atributos com seus getters e setters

}

Despois se estenderia da classe mãe

public class PessoaFisica extends Cliente{
private String cpf;

public void setCpf(String cpf){
this.cpf = cpf;
}
public String getCpf(){
return this.cpf;
}

}

Aí…quando vc for setar os dados para pessoa física…poderia ser assim

PessoaFisica pf = new PessoaFisica();

pf.setNome(“Cliente1”)

pf.setCpf(“123456789”);

leopoldof:

Na verdade seriam beans… que herdam da classe mãe…não classes abstratas…

public class Cliente{

private String nome;

public void setNome(String nome){
 this.nome = nome;
}
public String getNome(){
return this.nome;
}
//depois adiciona o restante dos atributos com seus getters e setters

}

Despois se estenderia da classe mãe

public class PessoaFisica extends Cliente{
private String cpf;

public void setCpf(String cpf){
this.cpf = cpf;
}
public String getCpf(){
return this.cpf;
}

}

Aí…quando vc for setar os dados para pessoa física…poderia ser assim

PessoaFisica pf = new PessoaFisica();

pf.setNome(“Cliente1”)

pf.setCpf(“123456789”);</blockquote>

Ok! Obriado pela ajuda.

Mais fiquei com dúvidas quanto ao atribotu da Classe Pessoa Juridica: No caso do atributo Tipo(comercial, industrial, serviços) Como eu devo colocar esse atributo, e como devo colocar nos metodos set e get?

leopoldof:

Na verdade seriam beans… que herdam da classe mãe…não classes abstratas…

Na pergunta ficou bme óbvio que a classe cliente deve ser abstrata. Com qual conceito vc muda isto e acha que nada será afetado no código ?!?!?!

O correto

public abstract class Cliente{
protected String nome; //Protected para permitir acesso às classes filhas.
// gets e sets
}

public class PessoaFisica extends Cliente {
private String cpf;
// gets e sets
}

Giulliano:

leopoldof:

Na verdade seriam beans… que herdam da classe mãe…não classes abstratas…

Na pergunta ficou bme óbvio que a classe cliente deve ser abstrata. Com qual conceito vc muda isto e acha que nada será afetado no código ?!?!?!

O correto

public abstract class Cliente{
protected String nome; //Protected para permitir acesso às classes filhas.
// gets e sets
}

O mais correto:

public abstract class Cliente{
private String nome; 
// gets e sets
}

A existencia de get/set já garante o acesso.

sergiotaborda:

O mais correto:

public abstract class Cliente{
private String nome; 
// gets e sets
}

A existencia de get/set já garante o acesso.

Não vejo como “mais errado” um atributo protected em uma classe abstrata, o modificador de acesso public seria uma péssima idéia na maioria das situações, mas proteced pode depender da sua necessidade e do seu design. Enfim…

Alguns autores até sugerem que se evite usar o modificador protected nos membros da classe, já que na maior parte dos casos ele pode ser trocado por visiblidade pública ou privada com apenas algumas alterações no desenvolvimento.

Giulliano:

sergiotaborda:

O mais correto:

public abstract class Cliente{
private String nome; 
// gets e sets
}

A existencia de get/set já garante o acesso.

Não vejo como “mais errado” um atributo protected em uma classe abstrata, o modificador de acesso public seria uma péssima idéia na maioria das situações, mas proteced pode depender da sua necessidade e do seu design. Enfim…

Veja, não é uma questão de gosto.
Se o get/set já é publico a classe filha pode acessar por ai. Não ha necessidade de abrir o atributo para protected. Occam’s Razor.

Se não tivessemos get/set ai seria diferente. O atributo continuaria privado e adicionariamos um get/set protected. Os atributos são sempre privados.
E métodos devem ser colocados com o nivel de acesso adquado para permitir a chamadas.

Existem várias razões para isto. Uma delas é o problema do sombreamento da classe filha. ela pode declarar um atributo com o mesmo nome e ai se perde todo. E a herança. Alguem pode modificar a implementação do get/set na hierarqui e vc não quer perder isso.

é vero por isso que eu disse que depende da sua necessidade, existem casos e casos. Mas não vou me aprofundar muito senão a discussão vai longe.