Fórum Modelagem OO em Delphi é Diferente de Java, vcs concordam? #281629
13/05/2005
0
Estou com um problema de ´comunicação´ com um amigo analista / programador de Java.
O problema é, ele fala que meu Diagrama de Classes está errado por que eu não modelo os atributos do banco de dados na classe.
No conceito da OO o diagrama de classe deve modelar dados e comportamento. Mas acho ´com muita certeza - rs´ que isso não aplica ao Delphi.
Realmente, eu não modelo os atributos. [b:2ef6470eba]pq não utilizo dessa forma[/b:2ef6470eba].
Utilizo ClientDataSet. Utilizo com comentes da ´família DB´. Ou seja, manipulo não os métodos Mutantes (Get e Set) e sim o Objeto ClientDataSet. E ele faz essa manipulação para mim indiretamente como todos sabem.
[b:2ef6470eba] Seria assim, vamos imaginar um Diag. de Classes de Pessoa em Delphi..[/b:2ef6470eba]
=Atributos / na verdade em Delphi é Propriedades QuantidadeRegistro EstadoTabela ClientDataSet <--- Objeto q manipulo os dados. ValorChavePrimaria =Métodos Salvar Inserir Bla Bla Bla
[b:2ef6470eba] Agora em Java.[/b:2ef6470eba]
=Atributos Nome: string Telefone: string Endereco: string =Métodos Salvar Inserir GetQuantidadeRegistro GetEstadoTabela GetValorChavePrimaria GetNome; SetNome; Bla Bla Bla
Agora aqui está o problema, ele fala que meu diagrama tem que ter os atributos da Classes (Nome, Endereco, Telefone e demais). Ou seja os campos que tenho no BD. Seria o equivalente em Java aos ´get´ e ´set´ para buscar e atribuir esses campos para persistencia.
No Delphi, graças a Deus temos a persistencia mais amigável. O ClientDataSet posso ligar no DataSource e ligar os camponentes da familia BD. Quando eu colocar (meu objeto) ManipulaBD.Salva (que faz um FClientDataSet.Post) eu estou fazendo o que ele faz mas sem utilizar os Get e Set manualmente. Concordam?
As 2 formas estão Orientada a Objeto na minha visão. Até olhando pelo Modelo MDA (Model-Driven Architecture) , existe o PSM (Plataform Specif Model) e o PIM (Plataform Independent Model). Acredito q essas modelagem são PSM, ou seja, é específica da linguagem, mas é OO.
O que vc´s acham sobre as modelagem apresentadas acimas, e como vc fazem suas classes, coloca os campos do banco de dados na modelagem ou omitem isso e utilzam as classes de apoio do Delphi que são o TDataSet e seus filhos? Agora a pergunta é, Vc´s concordam q as 2 formas são OO?
Pessoal não estou para falar bem ou mal das linguagens, acho q as 2 tem seus fins e seus seguidores. Gostaria de uma opnião parcial.
Obrigado pelo tempo.
Abraços.
:D
Yallebr
Curtir tópico
+ 0Posts
14/05/2005
Tnaires
Mas pela maneira q eu aprendi, os objetos do diagrama de classes são mapeados segundo seus atributos descritivos, e os métodos descrevem o comportamento desses atributos. Nesse modelo q vc mostrou do Delphi, vc mapeou na verdade, a tabela Pessoa (guardando atributos da tabela, como número de registros, etc), e não a classe Pessoa em si.
Veja como eu faço com Java: o usuário vai inserir um novo registro na tabela de Pessoas, então uma nova instância da classe Pessoa é criada. O usuário informa os valores dos atributos, que são ajustados pelos métodos ´Set´. Qdo o usuário vai gravar o registro, esse objeto é passado para uma camada d persistência (constituída de classes q vão analisar o objeto e gerar um SQL para ser passado pro banco - isso é feito usando Reflection), q tratará d gravar o registro no banco. Dessa maneira, o modelo do sistema fica completamente independente da implementação da camada d persistência. Essa é a vantagem, pq essa camada pode ser utilizada para vários outros sistemas, independente do modelo.
Vamos continuar nossa conversa, eu tenho mto interesse em conhecer a modelagem OO do Delphi.
Abraços
Gostei + 0
14/05/2005
Yallebr
Acredito que a modelagem sua fica independente da persistencia e vc consegue modelar Dados e Comportamento. Muito Bom.
Agora a que eu passei, também é independente da persistencia, pois TClientDataSet manipula dados, também independente do BD. O q faz minha dependencia ou não são os drivers que possuo no no DbExpress, esses drives que fariam a conexão e traduziam em comandos SQL para o BD. Acho q equivalente ao JDBC. Exceto que eu não precisaria passar comandos SQL diretamente, pois o Dephi traduz métodos (post, insert, refresh) em comandos SQL para o BD.
Mas se geramos seu código para Delphi, ficaria muito incosistente.
Realmente, eu não modelei os atributos das pessoas, como nome, end, e etc. Por que? Por que em Delphi não é comum (nem um pouco) utilizar métodos set e get para buscar dados e setar dados para BD.
Então no Delphi podemos dizer que o TDataSet é minha classe responsável por esse serviço, e isso fica transparente para o programador Delphi essa manipulacao.
Então na minha classe eu não manipulo os Atributos e sim um Objeto do Tipo TDataSet que ele sim manipula os dados. Responsável por salvar atributos e buscar do bd.
E quando eu preciso acessar ou salvar meus dados eu faço uma chamada a algum método do Objeto TDataSet que minha classe possui. Ex.
TManipulaBD = class(BD)
private
FClientDataSet: TClientDataSet;
public
Salva
end;
procedure TManipulaBD.Salva;
begin
FClientDataSet.Post; --> Esse comando seria responsável para fazer
o equivalente dos Set, e do comando SQL em java.
" ApplyUpdates.
end;
Ou seja, no Delphi não faria sentido eu modelar os atributos da classe, pois não manipularia isso manualmente, nem mesmo a conexão com vc falou. Pois teríamos as classes TDataSet e TCustomCOnnection que fazem isso através de componentes.
na minha opniao.
Queria a opniao dos Delphianos, Javianos e demais.
Abraço.
Gostei + 0
14/05/2005
Aroldo Zanela
Não tenho tido mais tempo de participar nos fóruns, principalmente em discussões deste nível, mas recomendo: www.oodesign.com.br/forum. Neste caso em específico, vejam: Mapeamento e persistência de Objetos.
Gostei + 0
14/05/2005
Aroldo Zanela
A propósito, quando você utilizar Data-Awares (DBs) não estará utilizando OO pura e sim RAD ou RID. Sim, as propriedades são os atributos e existem camadas de persistência como o tiOPF semelhante ao Hibernate (java).
Gostei + 0
15/05/2005
Yallebr
Obrigado, sim conheco o forum é excelente. Abri um tópico lá.
Abraços.
Gostei + 0
15/05/2005
Yallebr
Aroldo, acho q são padrões diferentes. OO visa reutilização de código, encapsulamente, abstração e outras varias técnicas. O RAD é uma forma de construir projetos de forma rápida e simples. Acho que são padrões q se casão. Por exemplo.
[b:e234e64886]JBulder é RAD. E e OO. Agora por ser RAD ele largou de ser OO puro e virou hibrida igual ao Delphi?[/b:e234e64886] Por isso q acho, o Java não é OO pura, hj em dia ela é hibrida igual ao Delphi dependendo da Framework que está sendo utilizando. Por ex. JBuilder, NetBeans tornam o Java não uma linguagem pura.
Outra coisa, não estou defendendo a OO pura. Ao contrário, acho q o sucesso de qualquer projeto não se chega apenas com uma tecnologia pura, mas sim na ´mistura´ de várias. OO, RAD, MDA, Designer pattern e demais.
Gostei + 0
16/05/2005
Tnaires
Gostei + 0
16/05/2005
Adisson
A modelagem de dados deve estar acima de qualquer peculiaridade das linguagens de programação. Na construção de diagramas de classes devemos esquecer como codificamos. Como o próprio nome representa ´modelagem´ é criar modelos independentes de plataformas.
De fato, Delphi é uma linguagem de programação orientada à objeto, isto não que dizer que qualquer programa (criado em delphi) seja orientado à obj. Na verdade devido ao forte encapsumamento o DELPHI leva a maioria dos programadores a desenvolver programas ´orientados a eventos´.
Então ao modelar muito cuidado, esqueça as ´facilidade´ do Delphi´ e pense em modelar de uma forma que um programador/analista de uma linguagem ´xxx´ compreende em sua totalidade a funcionalidade desta classe com todos seus atributos e eventos.
Gostei + 0
16/05/2005
Renatosilva
Gostei + 0
16/05/2005
Tnaires
Falou tudo e mais um pouco :wink:
Gostei + 0
16/05/2005
Aroldo Zanela
Aroldo, acho q são padrões diferentes. OO visa reutilização de código, encapsulamente, abstração e outras varias técnicas. O RAD é uma forma de construir projetos de forma rápida e simples. Acho que são padrões q se casão. Por exemplo.
[b:2327440cac]JBulder é RAD. E e OO. Agora por ser RAD ele largou de ser OO puro e virou hibrida igual ao Delphi?[/b:2327440cac] Por isso q acho, o Java não é OO pura, hj em dia ela é hibrida igual ao Delphi dependendo da Framework que está sendo utilizando. Por ex. JBuilder, NetBeans tornam o Java não uma linguagem pura.
Outra coisa, não estou defendendo a OO pura. Ao contrário, acho q o sucesso de qualquer projeto não se chega apenas com uma tecnologia pura, mas sim na ´mistura´ de várias. OO, RAD, MDA, Designer pattern e demais.[/quote:2327440cac]
Colega,
Eu entendo que Java utiliza OO pura, pois você não consegue fazer um simples ´Alô mundo´ sem criar uma classe e instanciá-la, ao passo que, Delphi é híbrida por permitir programação sem o uso de objetos e/ou ambos. Quando me referi ao uso de RAD (Application) ou RID (Integration) quiz me referir ao vício que tanto nos acostumamos em ´cumprir o cronograma´ e deixar de POO.
Gostei + 0
16/05/2005
Yallebr
Discordo de sua posição. Pois o diagrama de classe deve representar o código. Não faz sentido vc ter seu diagrama de classe apenas para ter. Ele DEVE gerar código. OU mesmo se eu fizer engenharia reversa devo ter o diagrama de classe.
A UML deve integrar com seu projeto, essa é a ideia dela. E não apenas fazer protótipos.
Diagrama de Classe é o principal diagrama da UML que gera código. Ele deve representar seu código específico da linguagem. Claro q a pessoa pode fazer um independente de plataforma e outro dependente para gerar código. Mas se não gerar código não faz sentido.
Ps. Não conheco ninguem q faz 2 diagramas de classes.
Abraços.
Gostei + 0
16/05/2005
Yallebr
Muito bom o Material.
Gostei + 0
17/05/2005
Aroldo Zanela
Discordo de sua posição. Pois o diagrama de classe deve representar o código. Não faz sentido vc ter seu diagrama de classe apenas para ter. Ele DEVE gerar código. OU mesmo se eu fizer engenharia reversa devo ter o diagrama de classe.
A UML deve integrar com seu projeto, essa é a ideia dela. E não apenas fazer protótipos.
Diagrama de Classe é o principal diagrama da UML que gera código. Ele deve representar seu código específico da linguagem. Claro q a pessoa pode fazer um independente de plataforma e outro dependente para gerar código. Mas se não gerar código não faz sentido.
Ps. Não conheco ninguem q faz 2 diagramas de classes.
Abraços.[/quote:c385735841]
Colega,
Nisto eu concordo contigo, pois quando utilizamos uma ferramenta CASE como o Together, chegamos a codificar em nível de programação OO (onde já devemos ter uma linguagem definida para uso), o que nos remete de volta ao início da thread e devemos pensar em objetos e não em conjunto de dados.
Gostei + 0
17/05/2005
Ericlemes
Pra mim, se vc está modelando num ClientDataset, pode ser modelagem orientada a qualquer coisa, menos a objeto. Vc não está encapsulando atributos, tampouco vai permitir, sei lá, herança disso. Não que não seja uma forma ou visão de se modelar...
Engraçado como todo mundo se preocupa em dizer ´meu projeto é OO´, ´meu projeto é RAD´, ´meu projeto é MDA´, mas ninguém se preocupa em ´PORQUE´ OO, ´PORQUE´ RAD, ´PORQUE´ MDA.
Pra mim, fazer um projeto orientado a objeto tem como primeiro objetivo encapsular regras de negócio, isolando-as de interfaces e/ou persistência. Tudo depende do nível de isolamento desejado.
No exemlpo que vc deu, um equivalente de modelagem OO pra mim em delphi seria:
TMinhaClasseNegocio = class
private
FMeuAtributo1: integer;
FMeuAtributo2: string
public
property MeuAtributo1: integer read FMeuAtributo1 write FMeuAtributo1;
...
end;
Sobre usar ou não o diagrama de classes para gerar código. Eu acho isso uma questão de opção... se faz questão de dizer que seu projeto é MDA, aí *precisa* ter. Eu já usei diagramas de classes para documentar somente a framework básica. Tinha um projeto OOP, mas não um projeto MDA.
O que eu sempre questiono quando estou discutindo se é OOP ou não é qual a motivação que as pessoas tem para escrever projetos dessa forma. A minha motivação é isolar o ´core´ do negócio da tecnologia. Ficar dependente do Delphi pra mim é quase q inevitável, mas ficar dependente de dbExpress, da VCL, ou de outros sets de componentes, é péssimo para manutenção a longo prazo. Se hoje eu fosse escrever um projeto pequeno, onde ser multi-banco ou ter várias IHC´s (Web e Client/Server, por exemlpo) não fosse um requisito, eu não teria o menor constrangimento em escrevê-lo não-OOP.
E o é mais engraçado ainda são os projetos em java ´OOP´, que possuem regra de negócio na interface com o usuário.
Isso é assunto pra muuuuuuuuuuuuuuuita discussão.
[]´s
Eric Lemes
Gostei + 0
Clique aqui para fazer login e interagir na Comunidade :)