Modelagem OO em Delphi é Diferente de Java, vcs concordam?
Olá pessoal,
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]
[b:2ef6470eba] Agora em Java.[/b:2ef6470eba]
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
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
Curtidas 0
Respostas
Tnaires
13/05/2005
Eu nunca usei modelagem com Delphi.
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
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
Yallebr
13/05/2005
Olá tnaires,
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.
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.
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.
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.
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
Aroldo Zanela
13/05/2005
Colegas,
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.
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
Aroldo Zanela
13/05/2005
Colega,
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).
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
Yallebr
13/05/2005
Olá Aroldo Zanela,
Obrigado, sim conheco o forum é excelente. Abri um tópico lá.
Abraços.
Obrigado, sim conheco o forum é excelente. Abri um tópico lá.
Abraços.
GOSTEI 0
Yallebr
13/05/2005
A propósito, quando você utilizar Data-Awares (DBs) não estará utilizando OO pura e sim RAD ou RID.
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
Tnaires
13/05/2005
Java e Object Pascal são as linguagens OO por trás dos ambientes RAD JBuilder e Delphi, respectivamente. Realmente, como vc falou, yallebr, as ferramentas RAD alteram um pouco o paradigma da linguagem, uma vez q elas introduzem recursos que aumentam a produtividade, mas muitas vezes sacrificam algumas de suas características. Entretanto, enquanto pudermos incrementar a produtividade sem abrir mão de reutilização e robustez, está bom.
GOSTEI 0
Adisson
13/05/2005
yallebr
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.
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
Renatosilva
13/05/2005
[url]http://www.guj.com.br/posts/list/23735.java[/url]
GOSTEI 0
Tnaires
13/05/2005
yallebr
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.
Falou tudo e mais um pouco :wink:
GOSTEI 0
Aroldo Zanela
13/05/2005
[quote:2327440cac]A propósito, quando você utilizar Data-Awares (DBs) não estará utilizando OO pura e sim RAD ou RID.
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
Yallebr
13/05/2005
Olá Adisson,
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.
Como o próprio nome representa ´modelagem´ é criar modelos independentes de plataformas.
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
Yallebr
13/05/2005
[url]http://www.guj.com.br/posts/list/23735.java[/url]
Muito bom o Material.
GOSTEI 0
Aroldo Zanela
13/05/2005
Olá Adisson,
[quote:c385735841]Como o próprio nome representa ´modelagem´ é criar modelos independentes de plataformas.
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
Ericlemes
13/05/2005
Assunto polêmico esse...
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
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
Aroldo Zanela
13/05/2005
Colegas,
Ainda acho que o melhor lugar para se discutir este assunto é no www.oodesign.com.br, mas aproveitando que alguns já agregaram bastante valor nesta thread, achei um artigo interessante: http://www.hu.ufsc.br/IX_CIBS/trabalhos/arquivos/268.pdf
Ainda acho que o melhor lugar para se discutir este assunto é no www.oodesign.com.br, mas aproveitando que alguns já agregaram bastante valor nesta thread, achei um artigo interessante: http://www.hu.ufsc.br/IX_CIBS/trabalhos/arquivos/268.pdf
GOSTEI 0
Yallebr
13/05/2005
ericlemes
Realmente.
Eric Lemes, realmente. Acho q existe uma vontate dos programadores e analistas de usarem esse termo. Mas acho difícil explicar o ´porque´. De preferencia utilizar todos eles, ´meu projeto é RAD, é OO, MDA, e ainda estruturado, rs rs´ 8)
Esse link mostra uns programadores Javas falando sobre isso tb.
[url]http://www.guj.com.br/posts/list/23735.java[/url]
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.
Realmente.
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.
Eric Lemes, realmente. Acho q existe uma vontate dos programadores e analistas de usarem esse termo. Mas acho difícil explicar o ´porque´. De preferencia utilizar todos eles, ´meu projeto é RAD, é OO, MDA, e ainda estruturado, rs rs´ 8)
Esse link mostra uns programadores Javas falando sobre isso tb.
[url]http://www.guj.com.br/posts/list/23735.java[/url]
GOSTEI 0
Moonlight
13/05/2005
Olá,
eu concordo totalmente com yalle que modelagem OO em Delphi é diferente de em Java.
Antigamente eu programava totalmente RAD e comecei aos poucos a querer passar para OOP, no que dei de cara com os frameworks de mapeamento O/R. Estudei, fiz alguns testes com DePO e ECO II recentemente, mas o que percebi que é usando esses frameworks eu perco uma coisa muito importante na OOP: a possibilidade de reutilizar totalmente o código. Acho que esses frameworks nos deixam muito presos.
Acabei adotando por uma solução a parte: uma classe de persistencia com alguns metodos pré-definidos, da qual faço descender outra classe de persistencia especifica para cada tabela. Daí se tenho a unit cadastro de clientes, tenho outra unit que é a classe de persistencia do cliente, que é filha da classe de persistência maior. Dentro da classe filha, faço uns get e set que validam os dados e jogam o valor pra propriedade. Por fim, um post (lembrando que uso tb os outros metodos como insert, update, delete, conforme necessario). Nao uso componentes DBaware.
Sobre essa minha prática: não faço ideia se tá mais ou menos legal ou se é uma completa gambiarra. Está funcionando - apesar de no começo terem havido alguns problemas com colecoes, hehe - e qdo eu preciso manipular a mesma tabela com outra aplicacao, aproveito as classes já feitas.
Alguém por favor me diz se a barbeiragem que tou fazendo é grave?
T+
eu concordo totalmente com yalle que modelagem OO em Delphi é diferente de em Java.
Antigamente eu programava totalmente RAD e comecei aos poucos a querer passar para OOP, no que dei de cara com os frameworks de mapeamento O/R. Estudei, fiz alguns testes com DePO e ECO II recentemente, mas o que percebi que é usando esses frameworks eu perco uma coisa muito importante na OOP: a possibilidade de reutilizar totalmente o código. Acho que esses frameworks nos deixam muito presos.
Acabei adotando por uma solução a parte: uma classe de persistencia com alguns metodos pré-definidos, da qual faço descender outra classe de persistencia especifica para cada tabela. Daí se tenho a unit cadastro de clientes, tenho outra unit que é a classe de persistencia do cliente, que é filha da classe de persistência maior. Dentro da classe filha, faço uns get e set que validam os dados e jogam o valor pra propriedade. Por fim, um post (lembrando que uso tb os outros metodos como insert, update, delete, conforme necessario). Nao uso componentes DBaware.
Sobre essa minha prática: não faço ideia se tá mais ou menos legal ou se é uma completa gambiarra. Está funcionando - apesar de no começo terem havido alguns problemas com colecoes, hehe - e qdo eu preciso manipular a mesma tabela com outra aplicacao, aproveito as classes já feitas.
Alguém por favor me diz se a barbeiragem que tou fazendo é grave?
T+
GOSTEI 0
Ericlemes
13/05/2005
Olá,
Não acho barbeiragem não... óbvio q vai ter muita gente que vai achar... quando eu tava questionando sobre o ´porque´ as coisas, queria entrar exatamente nesse assunto.
Tem muita gente usando frameworks de persistência, sem nem saber ao certo porque. Se for pra eu representar o modelo E/R numa classe, eu prefiro continuar gerando as queries na mão, e não ter mais uma dependência tecnológica no meu projeto.
O lance todo é que encapsular regra de negócio pra mim (única motivação minha para modelar um projeto OO) é bem diferente de simplesmente usar uma persistência de um modelo E/R (se levar em consideração o ´nível´ dos modelos E/R encontrados por aí, é pior ainda..).
O problema de fazer desse jeito, com uma classe de persistência específica para cada classe de negócio, acaba sendo mto trabalhoso e sujeito a erros...
O que eu estou procurando é um intermediário entre os dois... o encapsulamento das regras de negócio, sem ter todo o trabalho manual.
[]´s
Eric Lemes
Não acho barbeiragem não... óbvio q vai ter muita gente que vai achar... quando eu tava questionando sobre o ´porque´ as coisas, queria entrar exatamente nesse assunto.
Tem muita gente usando frameworks de persistência, sem nem saber ao certo porque. Se for pra eu representar o modelo E/R numa classe, eu prefiro continuar gerando as queries na mão, e não ter mais uma dependência tecnológica no meu projeto.
O lance todo é que encapsular regra de negócio pra mim (única motivação minha para modelar um projeto OO) é bem diferente de simplesmente usar uma persistência de um modelo E/R (se levar em consideração o ´nível´ dos modelos E/R encontrados por aí, é pior ainda..).
O problema de fazer desse jeito, com uma classe de persistência específica para cada classe de negócio, acaba sendo mto trabalhoso e sujeito a erros...
O que eu estou procurando é um intermediário entre os dois... o encapsulamento das regras de negócio, sem ter todo o trabalho manual.
[]´s
Eric Lemes
GOSTEI 0
Moonlight
13/05/2005
De que outra forma posso conseguir a mesma reusabilidade?
GOSTEI 0
Ericlemes
13/05/2005
Bom...
Eu já desenvolvi uma ´framework´ (não necessariamente um conjunto de componentes, e sim um conjunto de práticas + algumas classes básicas) para se desenvolver um projeto OOP em Delphi. Nessa framework usei os seguintes conceitos:
- Todas as classes de negócio, eram derivadas lá de TPersistent (só com recursos de RTTI), contendo atributos q refletiam minhas entidades no banco, porém, todas as classes relacioandas (FK´s) no banco, eram apontadas diretamente para outra classe, como por exemplo:
TPedido = class(TObjetoNegocio)
private
FPedidoID: integer;
FCliente: TCliente;
FItens: TObjetosNegocio;
...
end;
Dessa forma, eu conseguia, dentro da classe pedido, escrever toda e qualquer consistência relacionada a pedidos, coisa q não cnoseguia fazer com procedures perdidas no meio do nada (Ex.: SOA), sem utilizar estruturas de dados um pouco mais complexas e específicas por problemas. Por exemplo:
- Se eu precisasse consistir algo como ´O valor total dos itens é igual ao valor total do pedido´, eu poderia fazer percorrendo o Collection de itens de pedido, garantindo que ao gravar na base, o objeto estava consistente.
- Em SOA, como eu faria isso sem ter q ir na base?
Tendo esses objetos prontos, eu tinha uma framework de classes visuais (CLX) que sabiam ´conversar´ com esses objetos de negócio (visto q todos eles derivam de um mesmo nível TObjetoNegocio). Além dessa IHC, tinah uma segunda IHC Web, onde eu usava essas mesmas classes de negócio, porém com classezinhas de controle, q só tiravam parâmetros dos request e tacavam no objeto de negócio, que sabia se consistir.
A grande desvantagem dessa metodologia, foi que a persistência foi escrita na mão. Talvez o maior custo do projeto. Ela foi feita na mão, pq na época eu ainda não tinha mta habilidade com RTTI, tampouco consegui chegar num padrão para gravar por exemplo, o ID de um cliente relacionado ao Pedido (pq este estava em outra classe, associada por referência).
Em resumo.... faltou amadurecer um pouco a idéia, mas deu um passo além do q simplesmente fazer um modelo E/R exibido como classe. O que faltou foi chegar num custo/benefício melhor de desenvolvimento, porém, a reusabilidade dessa camada de negócio, foi 100¬, pq esta só tinha dependência de classes básicas do delphi (RTTI, Collections) e ClientDatasets (forma padrão para se pegar algo do banco).
Com isso, eu consegui um multi-banco de verdade (50¬ resolvido com queries ANSI na camada de negócio e 50¬ com uma classe abstrata de banco de dados ´TConexaoBancoDados´ que permitia q eu encapsulasse outros compoenntes de conexão. Na época, consegui PostgreSQL + Oracle + SQL + FireBird e parei no MySQL), e uma independência de interfaces.
Se quiser discutir melhor esse assunto, me mande MP, eu te passo um Messenger ou telefone. Essas discussões são mais ´filosóficas´ q técnicas, na minha opinião.
[]´s
Eric Lemes
Eu já desenvolvi uma ´framework´ (não necessariamente um conjunto de componentes, e sim um conjunto de práticas + algumas classes básicas) para se desenvolver um projeto OOP em Delphi. Nessa framework usei os seguintes conceitos:
- Todas as classes de negócio, eram derivadas lá de TPersistent (só com recursos de RTTI), contendo atributos q refletiam minhas entidades no banco, porém, todas as classes relacioandas (FK´s) no banco, eram apontadas diretamente para outra classe, como por exemplo:
TPedido = class(TObjetoNegocio)
private
FPedidoID: integer;
FCliente: TCliente;
FItens: TObjetosNegocio;
...
end;
Dessa forma, eu conseguia, dentro da classe pedido, escrever toda e qualquer consistência relacionada a pedidos, coisa q não cnoseguia fazer com procedures perdidas no meio do nada (Ex.: SOA), sem utilizar estruturas de dados um pouco mais complexas e específicas por problemas. Por exemplo:
- Se eu precisasse consistir algo como ´O valor total dos itens é igual ao valor total do pedido´, eu poderia fazer percorrendo o Collection de itens de pedido, garantindo que ao gravar na base, o objeto estava consistente.
- Em SOA, como eu faria isso sem ter q ir na base?
Tendo esses objetos prontos, eu tinha uma framework de classes visuais (CLX) que sabiam ´conversar´ com esses objetos de negócio (visto q todos eles derivam de um mesmo nível TObjetoNegocio). Além dessa IHC, tinah uma segunda IHC Web, onde eu usava essas mesmas classes de negócio, porém com classezinhas de controle, q só tiravam parâmetros dos request e tacavam no objeto de negócio, que sabia se consistir.
A grande desvantagem dessa metodologia, foi que a persistência foi escrita na mão. Talvez o maior custo do projeto. Ela foi feita na mão, pq na época eu ainda não tinha mta habilidade com RTTI, tampouco consegui chegar num padrão para gravar por exemplo, o ID de um cliente relacionado ao Pedido (pq este estava em outra classe, associada por referência).
Em resumo.... faltou amadurecer um pouco a idéia, mas deu um passo além do q simplesmente fazer um modelo E/R exibido como classe. O que faltou foi chegar num custo/benefício melhor de desenvolvimento, porém, a reusabilidade dessa camada de negócio, foi 100¬, pq esta só tinha dependência de classes básicas do delphi (RTTI, Collections) e ClientDatasets (forma padrão para se pegar algo do banco).
Com isso, eu consegui um multi-banco de verdade (50¬ resolvido com queries ANSI na camada de negócio e 50¬ com uma classe abstrata de banco de dados ´TConexaoBancoDados´ que permitia q eu encapsulasse outros compoenntes de conexão. Na época, consegui PostgreSQL + Oracle + SQL + FireBird e parei no MySQL), e uma independência de interfaces.
Se quiser discutir melhor esse assunto, me mande MP, eu te passo um Messenger ou telefone. Essas discussões são mais ´filosóficas´ q técnicas, na minha opinião.
[]´s
Eric Lemes
GOSTEI 0