OOP - DTO E HERANCA!!
Pessoas bom dia,
Estou num projeto grande e estou precisando de uma luz!
é o seguinte,o projeto tem diversas classes e umas delas são Super classes,a questão fica,
Como eu irei trabalhar com os atributos e os metodos??
Vamos supor que eu tenho a classe Pessoa e classe Diaristas,Alunos,Professores.Tudo herdando de pessoas
no diagrama de classe.
Os atributos,como nome,sexo,endereço ficam aonde?
Dentro da Super_cPessoa(Onde vai ter os metodos)?
Crio uma DTO (Classe onde só contem atributos) para cada caso ou seja
crio uma classe espelho do banco?
Obs:Cada metodo da classe pessoa,eu estou recebendo como parametro o Objeto e nao os atributos.como estou acostumado,
crio uma classe DTO,encapsulo os dados e passo a DTO ao inves dos dados separados.
E agora?!
Estou num projeto grande e estou precisando de uma luz!
é o seguinte,o projeto tem diversas classes e umas delas são Super classes,a questão fica,
Como eu irei trabalhar com os atributos e os metodos??
Vamos supor que eu tenho a classe Pessoa e classe Diaristas,Alunos,Professores.Tudo herdando de pessoas
no diagrama de classe.
Os atributos,como nome,sexo,endereço ficam aonde?
Dentro da Super_cPessoa(Onde vai ter os metodos)?
Crio uma DTO (Classe onde só contem atributos) para cada caso ou seja
crio uma classe espelho do banco?
Obs:Cada metodo da classe pessoa,eu estou recebendo como parametro o Objeto e nao os atributos.como estou acostumado,
crio uma classe DTO,encapsulo os dados e passo a DTO ao inves dos dados separados.
E agora?!
Imagine a situação:
Classe Homem
propriedade Sexo
propriedade Altura
propriedade Visão
Metodo Caminhar
Classe Super-Homem -> herda de homem
Metodo Voar
Propriedade VisãoRaioX - Sobrepondo visão
As propriedades, são colocadas à classe a qual elas pertencem. Veja o caso da visão nas classes acima. Super-homem, tem visão, mas ela sobrepõe a classe Visão do homem. Sexo e Idade, são caracterÃsticas de pessoas, portanto, são propriedades da classe pessoa. Já endereço, pode pertencer não somente à uma pessoa e uma pessoa pode ter vários endereços, portanto endereço deve ser uma classe distinta ao qual as pessoas(ou diaristas, professores, alunos, que são classes que herdam de pessoas) devem conter uma lista de endereços e não um único endereço. Ficando mais ou menos assim:
classe Cidade
Nome
UF
classe Endereço
Logradouro
Numero
Cidade - Instância de classe [Ô]Cidade
Complemento
classe Pessoa
Sexo
Idade
Nome
Lista<Endereço> - Lista de instância da classe endereço
classe Professor - > Pessoa
Lista<Disciplinas> //um professor, pode lecionar mais de uma disciplina, portanto, essa propriedade deve ser uma lista
Lista<Graduação> //mesmo caso acima
MatrÃcula //Essa é uma propriedade especÃfica do professor, portanto, deve ficar na classe professor, ainda que essa herde Pessoa
classe Diarista -> Pessoa
Setor de trabalho
Salário
classe Aluno -> Pessoa
Ano
Turma
Classe
PerÃodo - Manhã, tarde ou noite
Com essa estrutura, imagine um aluno, por herdar de outras classes que por sua vez herdam de outras, teria a estrutura:
classe Aluno
Ano
Turma
Classe
PerÃodo - Manhã, tarde ou noite
Lista<Endereço> -> propriedade herdada
Logradouro
Numero
Cidade
Nome
UF
Complemento
Sexo -> propriedade herdada
Idade -> propriedade herdada
Classe Homem
propriedade Sexo
propriedade Altura
propriedade Visão
Metodo Caminhar
Classe Super-Homem -> herda de homem
Metodo Voar
Propriedade VisãoRaioX - Sobrepondo visão
As propriedades, são colocadas à classe a qual elas pertencem. Veja o caso da visão nas classes acima. Super-homem, tem visão, mas ela sobrepõe a classe Visão do homem. Sexo e Idade, são caracterÃsticas de pessoas, portanto, são propriedades da classe pessoa. Já endereço, pode pertencer não somente à uma pessoa e uma pessoa pode ter vários endereços, portanto endereço deve ser uma classe distinta ao qual as pessoas(ou diaristas, professores, alunos, que são classes que herdam de pessoas) devem conter uma lista de endereços e não um único endereço. Ficando mais ou menos assim:
classe Cidade
Nome
UF
classe Endereço
Logradouro
Numero
Cidade - Instância de classe [Ô]Cidade
Complemento
classe Pessoa
Sexo
Idade
Nome
Lista<Endereço> - Lista de instância da classe endereço
classe Professor - > Pessoa
Lista<Disciplinas> //um professor, pode lecionar mais de uma disciplina, portanto, essa propriedade deve ser uma lista
Lista<Graduação> //mesmo caso acima
MatrÃcula //Essa é uma propriedade especÃfica do professor, portanto, deve ficar na classe professor, ainda que essa herde Pessoa
classe Diarista -> Pessoa
Setor de trabalho
Salário
classe Aluno -> Pessoa
Ano
Turma
Classe
PerÃodo - Manhã, tarde ou noite
Com essa estrutura, imagine um aluno, por herdar de outras classes que por sua vez herdam de outras, teria a estrutura:
classe Aluno
Ano
Turma
Classe
PerÃodo - Manhã, tarde ou noite
Lista<Endereço> -> propriedade herdada
Logradouro
Numero
Cidade
Nome
UF
Complemento
Sexo -> propriedade herdada
Idade -> propriedade herdada
Boa KERPLUNK!.
Entao quer dizer,que eu posso ter classes herdando uma SuperClasse e ao mesmo tempo tendo atributos especificos?
no caso de pessoa F e J que herda da classe pessoa,POREM classe fisica CPF,e juridica CNPJ,ou seja,atributos diferentes?!
Entao quer dizer,que eu posso ter classes herdando uma SuperClasse e ao mesmo tempo tendo atributos especificos?
no caso de pessoa F e J que herda da classe pessoa,POREM classe fisica CPF,e juridica CNPJ,ou seja,atributos diferentes?!
Exato. Você pode ainda melhorar isso, crie duas classes, uma chamada [Ô]PessoaFisica[Ô], que vai conter os dados da pessoa fÃsica, e uma chamada [Ô]PessoaJuridica[Ô](nem preciso dizer o que ela vai conter 
)
Então na classe pessoa, coloque uma propriedade chamada [Ô]Fisica[Ô] cujo tipo de dados é [Ô]FÃsica[Ô] e outra chamada [Ô]JurÃdica[Ô] que vai ser uma instância da classe pessoa jurÃdica.
Na classe Pessoa, coloque uma propriedade que indique o tipo de pessoa. Quando criar a instância da classe e preencher seus dados, verifique o campo [Ô]TipoPessoa[Ô], se for [Ô]F[Ô] busque os dados da pessoa fÃsica e [Ô]J[Ô]... bem você deve ter entendido a idéia... hehehe
) Então na classe pessoa, coloque uma propriedade chamada [Ô]Fisica[Ô] cujo tipo de dados é [Ô]FÃsica[Ô] e outra chamada [Ô]JurÃdica[Ô] que vai ser uma instância da classe pessoa jurÃdica.
Na classe Pessoa, coloque uma propriedade que indique o tipo de pessoa. Quando criar a instância da classe e preencher seus dados, verifique o campo [Ô]TipoPessoa[Ô], se for [Ô]F[Ô] busque os dados da pessoa fÃsica e [Ô]J[Ô]... bem você deve ter entendido a idéia... hehehe
Em se tratando de criação do seu framework, existem duas premissas que se seguidas, levam ao sucesso:
1 - À Cécar o que é de César: Cada entidade, deve conter as propriedades inerentes à ela. Um carro, não pode ter a propriedade [Ô]Envergadura[Ô], essa propriedade pertence à outra classe e não deve ser incluÃda na classe [Ô]Carro[Ô];
2 - Quanto mais granulado, melhor: Entender o que é o que, nem sempre é fácil. Apesar de quando dizemos [Ô]Contato[Ô](um e-mail, endereço, telefone, msn, facebook), automaticamente atribuÃmos isso à uma Pessoa. Mas [Ô]Contato[Ô], é uma classe de dados, que uma pessoa possui. Imagine se você quer ter o [Ô]Contato[Ô] para cada pessoa. Você não vai adicionar os campos da classe [Ô]Contato[Ô] na classe [Ô]Pessoa[Ô]. Ao invés disso, crie outra classe que vai conter os dados de contato e na classe [Ô]Pessoa[Ô], crie uma propriedade com o tipo de dados [Ô]Contato[Ô]. Assim, além de você separar as coisas, você vai poder adicionar multiplicidade. Uma pessoa, pode ter <N> contatos, ou seja, vários endereços, vários telefones, vários e-mails. E esses dados devem ser tratados de forma distinta, embora intimamente ligados à [Ô]Pessoa[Ô], são dados distintos.
1 - À Cécar o que é de César: Cada entidade, deve conter as propriedades inerentes à ela. Um carro, não pode ter a propriedade [Ô]Envergadura[Ô], essa propriedade pertence à outra classe e não deve ser incluÃda na classe [Ô]Carro[Ô];
2 - Quanto mais granulado, melhor: Entender o que é o que, nem sempre é fácil. Apesar de quando dizemos [Ô]Contato[Ô](um e-mail, endereço, telefone, msn, facebook), automaticamente atribuÃmos isso à uma Pessoa. Mas [Ô]Contato[Ô], é uma classe de dados, que uma pessoa possui. Imagine se você quer ter o [Ô]Contato[Ô] para cada pessoa. Você não vai adicionar os campos da classe [Ô]Contato[Ô] na classe [Ô]Pessoa[Ô]. Ao invés disso, crie outra classe que vai conter os dados de contato e na classe [Ô]Pessoa[Ô], crie uma propriedade com o tipo de dados [Ô]Contato[Ô]. Assim, além de você separar as coisas, você vai poder adicionar multiplicidade. Uma pessoa, pode ter <N> contatos, ou seja, vários endereços, vários telefones, vários e-mails. E esses dados devem ser tratados de forma distinta, embora intimamente ligados à [Ô]Pessoa[Ô], são dados distintos.
Obrigado amigo!..
Entendi sim perfeito,o problema mesmo ta sendo o conceito,estou a pouco tempo programando em OOP hehe..
valeu,qualquer coisa eu volto a abrir o topico!.
Abraços
Entendi sim perfeito,o problema mesmo ta sendo o conceito,estou a pouco tempo programando em OOP hehe..
valeu,qualquer coisa eu volto a abrir o topico!.
Abraços
Uma outra pergunta,como fica as camadas nessa historia?
A camada de negocio e a camada de acesso a dados?
A camada de negocio e a camada de acesso a dados?
Essas camadas conterão métodos que fazem algo com um objeto, que pode ser tanto uma classe quer herde outras como uma classe sem herança, isso tanto faz.
Imagine a classe DAL(Data Access Layer) correspondente as funções de aluno. Um método de inserção, teria como parâmetro um objeto Aluno que herda de pessoa. A classe [Ô]Aluno[Ô], conterá várias propriedades, algumas herdadas e outras não. As propriedades herdadas, naturalmente estarão em outra tabela. Por exemplo [Ô]Endereço[Ô]: Na tabela endereço, vai existir os dados do endereço(com alguma chave primária, para identificação), se um aluno pode possuir mais de um endereço, você vai criar uma tabela relacional de Endereços->Aluno(lê-se Endereços para aluno). Essa tabela de relacionamento, vai conter um campo chave(geralmente auto-enumerado ou uniqueidentifier), um campo [Ô]Endereço[Ô], que vai conter o código do endereço e um campo [Ô]Aluno[Ô] que vai conter o código do aluno, mais ou menos assim:
Tabela Aluno:
Código; Ano; Classe; Turma; PerÃodo
99; 2; 3B; A; Noturno
Tabela Endereço:
Código; Logradouro; Numero; Complemento;Cidade
25; Rua XXXX ; 46; ; 19 -> que vai estar na tabela [Ô]Cidade[Ô], com o código 19
42; Rua Ipê ; 315; Ap: 17 ; 22 -> que vai estar na tabela [Ô]Cidade[Ô], com o código 22
ID;Aluno; Endereço
1 ; 99 ; 25
2; 99 ; 42
Assim, quando montar a entidade [Ô]Aluno[Ô], faça uma procura na tabela de relacionamento de endereços para alunos, onde o campo aluno, contenha o código do aluno, resultando em todos os endereços que estão vinculados ao aluno... O mesmo raciocÃnio, para Professores e Diarista.
Esse é o relacionamento 1 para <N> que na verdade pode ser Suprimido com uma chave extrangeira de múltiplos. Eu prefiro fazer dessa maneira, porque acho que fica mais claro e possibilita acréscimo de informações(campos) nas tabelas relacionadas(no caso, Aluno e Endereço), sem precisar alterar a tabela de relacionamentos.
Imagine a classe DAL(Data Access Layer) correspondente as funções de aluno. Um método de inserção, teria como parâmetro um objeto Aluno que herda de pessoa. A classe [Ô]Aluno[Ô], conterá várias propriedades, algumas herdadas e outras não. As propriedades herdadas, naturalmente estarão em outra tabela. Por exemplo [Ô]Endereço[Ô]: Na tabela endereço, vai existir os dados do endereço(com alguma chave primária, para identificação), se um aluno pode possuir mais de um endereço, você vai criar uma tabela relacional de Endereços->Aluno(lê-se Endereços para aluno). Essa tabela de relacionamento, vai conter um campo chave(geralmente auto-enumerado ou uniqueidentifier), um campo [Ô]Endereço[Ô], que vai conter o código do endereço e um campo [Ô]Aluno[Ô] que vai conter o código do aluno, mais ou menos assim:
Tabela Aluno:
Código; Ano; Classe; Turma; PerÃodo
99; 2; 3B; A; Noturno
Tabela Endereço:
Código; Logradouro; Numero; Complemento;Cidade
25; Rua XXXX ; 46; ; 19 -> que vai estar na tabela [Ô]Cidade[Ô], com o código 19
42; Rua Ipê ; 315; Ap: 17 ; 22 -> que vai estar na tabela [Ô]Cidade[Ô], com o código 22
ID;Aluno; Endereço
1 ; 99 ; 25
2; 99 ; 42
Assim, quando montar a entidade [Ô]Aluno[Ô], faça uma procura na tabela de relacionamento de endereços para alunos, onde o campo aluno, contenha o código do aluno, resultando em todos os endereços que estão vinculados ao aluno... O mesmo raciocÃnio, para Professores e Diarista.
Esse é o relacionamento 1 para <N> que na verdade pode ser Suprimido com uma chave extrangeira de múltiplos. Eu prefiro fazer dessa maneira, porque acho que fica mais claro e possibilita acréscimo de informações(campos) nas tabelas relacionadas(no caso, Aluno e Endereço), sem precisar alterar a tabela de relacionamentos.
Blza,é exatamente como eu estou fazendo!...
Valeu KERPLUNK!!!.
Abraçao brother..matou uma duvida cruel!
Valeu KERPLUNK!!!.
Abraçao brother..matou uma duvida cruel!
Tópico encerrado , respostas não são mais permitidas