| Autor |
Mensagem |
|
|
Isso
publics e globais.
|
 |
|
|
Possuo um componente de acesso aos dados com as seguintes características:
Dados
Dados.DCliente.nome
Dados.DCliente.endereço
Dados.DCliente.cpf
E tenho que apresentar isso em uma tela de cadastro.
Quais são as classes que eu tenho que criar para uma boa modelagem?
Os dados do cliente já estão em Dados.DCliente.nome, etc.
Crio ainda a Classe Cliente, com getNome, getEndereco, etc? Mesmo tendo Dados.DCliente.nome, etc?
E cadastro?
Crio tipo:
Cadastro.campoTextoNome = cliente.getNome()?
Cadastro.show();
|
|
|
|
Em um Set ou Get é sempre melhor dar sets e gets em todos os campos ou há alguns casos em que é preperível dar sets em uma estrutura que seria coleção de váriso dados?
|
|
|
|
|
|
|
|
Pois é.
O programa necessita de todas as funções que você citou.
|
|
|
|
|
vlw
|
|
|
|
|
vlw
|
|
|
|
A entidade Pessoa pode ser mudado para um nome melhor como DadosBasicos, pois não refleteria nenhum pessoa em si.
Tanto é que até pensei em colocar esses atributos como uma agregação, mas essa classe teria métodos de pesquisa no banco de dados. Aqui teria que usar SQL (e não persistência).
Por isso Dados básicos teria métodos que inserisse dados, cliente teria métodos que inserisse dados. E algum método (Transacao) faria em join nisso dado commit.
Cliente é Cliente, Fornecedor é Fornecedor, Vendedor é Vendedor. Eles podem sim assumir eventualmente o mesmo pepel. Ex: Eu sou Um Vendedor e vou vender um produto pra mim mesmo.
O que temos também é a Entidade Usuário, responsável por fazer login no sistema, mas não necessarimaente é um Vendedor.
Pessoa Jurídica, e Física também deveram ser distinguidadas. Algumas funções somente ficarão disponíveis pra PJ por exemplo.
Esses dados em comuns incluíria CPJ e CNPJ que teria o valor NULL (no banco) dependendo do caso.
|
|
|
|
Entendido.
|
|
|
|
Tá, você criou interface Pessoa, então como fica o caso de: "Uma interface não pode possuir atributos de instância"
?
Já que existem atributos comuns entre Cliente, Fornecedor, Vendedor.
Talvez fosse ideal criar uma classe agregada, onde teria um tipo de dados.
|
|
|
|
Obrigado, parece bem interessante.
|
|
|
|
|
André Fonseca, nesse caso eu não teria que cadastratar obrigatoriamente que cadastar uma Cliente, Fornecedor e Vendedor para que seja possível montar a SuperPessoa? Então se eu cadastrar um Cliente ele seria também um Vendedor, o que nem sempre é verdade.
|
|
|
|
Então, nesse caso eu necessitaria de implementar todos os métodos em SuperPessoa.
Se por virtude eu precisar modificar a classes Cliente, eu teria que modificar a SuperPessoa também. Aí seria pareciso se eu nem tivesse Cliente, Fornecedor, Vendedor... Criaria tudo em SuperPessoa.
Talvez seja mesmo o único jeito, pois já que um Cliente pode ser também Vendedor, Fornecedor... E SuperPessoa cuidaria disso... De alguma forma seria obrigatório existir uma classe única que integrasse Cliente, Fornecedor, Vendedor...
Acredito que é mesmo o melhor jeito.
|
|
|
|
Tenho os seguintes papeis: Cliente, Fornecedor, Vendedor
Essas classes tem em comum, o endereço, como rua, telefone, e-mail, etc (uns 20 atributos).
Esses dados poderiam estar em uma classe Pessoa?
Mas aqui eu tenho o caso de por exemplo um Vendedor também poder assumir o papel de Cliente.
Qual a melhor forma de modelar isso? Eu criaria a classe Pessoa referentes a dados pessoais?
Quais a relação de classes que eu faria a herença ou agregação?
Usaria polimorfismo? Também não seria o caso, pois Cliente, Fornecedor e Vendedor possuem alguns atributos e métodos específicos.
Além disso, Cliente e Fornecedor possui outro atributos em comum mas que não fa parte de Vendedor. Nesse caso (como é somente um atributo), acredito que seria melhor que ele fique em Cliente e Fornecedor.
Essa abordagem é necessária por que minha aplicação possui um método que é responsável importar dados em comum, ou seja: O usuário da aplicação cadastra um Cliente, mas se ele quiser pode recuperar os dados em comum (como endereço, tel, etc), para não ter que digitar tudo novamente para efetuar o cadastro de Vendedor ou Fornecedor.
|
|
|
|
Olá pessoal,
Aqui temos uma aplicação de automação comercial em Clipper e queremos mudar para uma linguagem orientada a objetos.
Nós queremos algo de baixo custo e encontramos aqui duas opções:
Desenvolver em Lazarus: Praticamente compatível com Delphi e atualmente julgamos como melhor solução.
Desenvolver em Java: Achamos muito complexo para dar retorno a curto prazo.
Eu queria a opinião de vocês, se a gente escolhesse o Java, por onde começar o desenvolvimento de nosso aplicativo, ou seja o que nós deveríamos aprender de Java para que isso fosse possível.
O que já sabemos: Orientação a Objetos, o Básico de Java (como swing, containers, layouts, etc), agora o que falta?
Mais detalhes sobre a aplicação: O software trabalha em modo aluguel do cliente, ou seja, Nós temos três servidores e o cliente tem uma aplicação que trabalha com cadastro de produtos, clientes, boletos, impressora fical, etc. Aí o cliente envia e recebe os dados para nossos servidores, usando o banco de dados firebird.
Alguém poderia dar umas dicas?
|
|
|
|
|
|