[quote=drsmachado]Camarada, não enxergo. Primeiro que esta regra de um cliente poder ser PJ e PF está, no MEU ponto de vista, errada.
Afinal, o cadastro será feito por CPF/CNPJ, não? Um PF associado a um CPF, um PJ a um CNPJ.
Além do mais, um Cliente podendo ser PJ e PF ao mesmo tempo, requeriria herança múltipla. Inexiste no java.
Há meios sim, de se obter um objeto filho a partir de uma instância da classe Pai, utilizando cast
Pessoa p = new PessoaFisica();
PessoaFisica pf = (PessoaFisica) p;
Plenamente possivel.[/quote]
Desse jeito eu enxergo os atributos, mas como vou salvar eles na minha classe Cliente
lembrando que individual so repassa os atributos pq ela é uma superclass
IPessoa é ruim demais! Eu não gosto… Nomenclatura ultrapassada. Quando eu vejo alguém usando essa nomenclatura desconfio na hora… Isso é pré-histórico e me lembra EJB1.
A questão principal é que não existe uma pessoa que não seja PessoaFísica ou PessoaJurídica, certo? Em outras palavras vc nunca vai instanciar Pessoa, mas apenas PessoaJuridica e PessoaFisica, certo? Pessoa então é apenas uma ESPECIFICACAO e não uma IMPLEMENTACAO.
Se esse for o caso então vc tem:
public interface Pessoa {
}
public abstract class AbstractPessoa implements Pessoa {
}
public class PessoaFisica extends AbstractPessoa {
}
public class PessoaJuridica extends AbstractPessoa {
}
Qualquer coisa diferente disso está errado.
OBS: A class AbstractPessoa é opcional mais recomendável.
A questão principal é que não existe uma pessoa que não seja PessoaFísica ou PessoaJurídica, certo? Em outras palavras vc nunca vai instanciar Pessoa, mas apenas PessoaJuridica e PessoaFisica, certo? Pessoa então é apenas uma ESPECIFICACAO e não uma IMPLEMENTACAO.
Se esse for o caso então vc tem:
public interface Pessoa {
}
public abstract class AbstractPessoa implements Pessoa {
}
public class PessoaFisica extends AbstractPessoa {
}
public class PessoaJuridica extends AbstractPessoa {
}
Qualquer coisa diferente disso está errado.
OBS: A class AbstractPessoa é opcional mais recomendável.
E se vc quiser/precisar vc tb pode fazer o client SER uma pessoa, implementando Pessoa e delegando.
Qualquer coisa diferente disso está errado.
Assim:
public class Client implements Pessoa {
private final Pessoa p;
public Client(Pessoa p) {
this.p = p;
}
// implementa os métodos de Pessoa e delega para p
}
Esse é o PATTERN decorator, o único que serve para alguma coisa. O resto é balela. Agora use esse pattern demais e vc fica com um sistema no estilo boneca-russa que ninguém entende. É para usar com muita parcimônia. Se vc está usando muito esse pattern significa que vc está complicando o simples. Por exemplo: Vc realmente precisa de dois objetos, Cliente e Pessoa !!!??? Não pode ser um só? Vc acabou de fazer o que 95% dos programadores fazem. Criou complexidade desnecessária para encher a boca e dizer: EU USEI O PATTERN DECORATOR !
mas nesse seu exemplo como trataria Cliente[/quote]
Leia isso que eu editei:
Não entendi a sua pergunta. Cliente é Cliente AND Cliente é Pessoa. Claro que Pessoa não é Cliente.
Conclusão: Vc introduziu complexidade no seu sistema. Para tudo e veja se não pode fazer um merge de Pessoa e Cliente numa classe só. Vai simplificar o seu sistema bastante.
[quote=saoj]IPessoa é ruim demais! Eu não gosto… Nomenclatura ultrapassada. Quando eu vejo alguém usando essa nomenclatura desconfio na hora… Isso é pré-histórico e me lembra EJB1.
[/quote]
Por isso eu coloquei isto no código
//IPessoa -- não use I antes de uma interface, neste caso, é um exemplo apenas.
public interface IPessoa{
Eu estou usando herança e tratando cliente como pessoa
so vou ter acesso aos atributos do pai
e não das filhas, se eu estende a classe Pessoa
como eu trataria isso
Você acha um erro trabalhar com herança nessa parte?
[quote=saoj]O cliente vai CONTER (composicao) uma Pessoa.
E se vc quiser/precisar vc tb pode fazer o client SER uma pessoa, implementando Pessoa e delegando.
Qualquer coisa diferente disso está errado.
Assim:
public class Client implements Pessoa {
private final Pessoa p;
public Client(Pessoa p) {
this.p = p;
}
// implementa os métodos de Pessoa e delega para p
}
Esse é o PATTERN decorator, o único que serve para alguma coisa. O resto é balela. Agora use esse pattern demais e vc fica com um sistema no estilo boneca-russa que ninguém entende. É para usar com muita parcimônia. Se vc está usando muito esse pattern significa que vc está complicando o simples. Por exemplo: Vc realmente precisa de dois objetos, Cliente e Pessoa !!!??? Não pode ser um só? Vc acabou de fazer o que 95% dos programadores fazem. Criou complexidade desnecessária para encher a boca e dizer: EU USEI O PATTERN DECORATOR ![/quote]
@Entity
@Table(name="PERSON")
@Inheritance(strategy=InheritanceType.JOINED)
@DiscriminatorColumn(name="PERSON_TYPE" , discriminatorType=DiscriminatorType.STRING)
public abstract class Person implements Serializable{
/**
*
*/
private static final long serialVersionUID = 1L;
@Id
@GeneratedValue(strategy=GenerationType.IDENTITY)
@Basic(optional=false)
private Long id;
@OneToOne(mappedBy="person",fetch=FetchType.EAGER, cascade=CascadeType.ALL)
private Address address;
@OneToOne(mappedBy="person",fetch=FetchType.EAGER, cascade=CascadeType.ALL)
private Login login;
.
.
.
Classe Pessoa Fisica
@MappedSuperclass
public class Individual extends Person{
/**
*
*/
private static final long serialVersionUID = 1L;
@NotNull
@NotEmpty
@Column(name="NAME", length=100, nullable=false)
private String name;
@NotNull
@NotEmpty
@Column(name="LAST_NAME", length=100, nullable=false)
private String lastName;
@NotNull
@NotEmpty
@Column(name="CPF")
private String cpf;
Classe Pessoa Juridica
@MappedSuperclass
public class Company extends Person implements Serializable{
private static final long serialVersionUID = 1L;
@NotNull
@NotEmpty
@Column(name="FOUNDATION_OF_DATE",length=10,nullable=false)
private Date foundationOfDate;
@NotNull
@NotEmpty
@Column(name="CTR", unique=true,length=15,nullable=false)
private String ctr;
@NotNull
@NotEmpty
@Column(name="CNPJ", unique=true,length=15,nullable=false)
private String cnpj;
A classe Cliente eu nao tenho nada pq estou procurando uma solução para implementar ela nesse modelo que estou passando
[quote=saoj][quote=tmvolpato]
Saoj,
Eu estou usando herança e implementando Pessoa
so vou ter acesso aos atributos do pai
e não das filhas
como eu trataria isso
Você acha um erro trabalhar com herança nesse modelo por exemplo?
[/quote]
Posta o código, por favor. Descrever código e arquitetura com palavras é conversa de maluco.[/quote]
Person tem que ser INTERFACE e nunca uma classe Abstrata. Espero que não seja o maravilhoso Hibernate que está te obrigando a fazer isso. Vc tem que usar aquele esquema de interface mais classes abstratas que eu postei. Vc já viu como as Collections do Java foram feitas?
A solucao do Cliente é aquela que eu postei.
Já no banco de dados tu vai ter duas tabelas. Uma para guardar os dados de PessoasJuridicas e outra para guardar os dados da pessoa física. E vc pode carregar todos os tipos de clientes ao mesmo tempo fazendo um JOIN em ambas as tabelas porque será garantido que um cliente não terá ambos.
AGORA TENTA ORGANIZAR ESSA ZONA COM AS ANOTACOES DO HIBERNATE ???
Hibernate cria um problema maior e não soluciona nada. Faca isso na mão com o bom e velho SQL. Banco-de-dados não dá para “abstrair” como o Hibernate tenta fazer. É uma insanidade e uma atente contra o principio KISS.
O único jeito correto de abstrair o banco-de-dados é usando DAOs e um query-builder com um mapeamento bem simples tipo o MentaBean faz. Inventar mágica e anotacoes malucas como o Hibernate faz é insanidade.
É aprender espanhol em cima de ingles para falar ingles melhor.
[quote=tmvolpato]duvida aqui
ao implementar a interface Pessoa em Cliente
vou obter todos os atributos da classe Fisica e juridica
seria isso o correto? ou teria outra maneira?
[/quote]
Não entendi. O que vc falou não faz sentido.
Quando o Cliente implementa Pessoa ele vai ter que RECEBER uma Pessoa no construtor, que pode ser qualquer uma.
Daí ele vai DELEGAR todos os métodos de pessoa para esse objeto que ele recebe no construtor. O famoso e infame DECORATOR pattern.
Vc diz que PessoaJuridica e PessoaFisica não possuem uma interface comum ??? Aí ferrou !!! Esquece tudo que eu falei então.
