Classes de dados e classes de lógica

Programação Arquitetura
#21

Cara, pode explicar por que parece isso para você? Partindo a pergunta em pedacinhos:

  • o que diabos é a “identidade” do banco, e onde ela se perde? :smiley:
  • por que uma classe que tem atributos e métodos como qualquer outra classe dificulta reuso? E ela se acopla a quê?
  • falou sobre “divisão de responsabilidades”. Como já foi discutido em alguns tópicos aqui, descobrimos que é possível ter persistência e objeto de negócio convivendo em paz de algumas maneiras, portanto onde reside o problema?

ps.: estou perguntando na boa cara \o/

#22

Não entendi a imagem do Lipe e, Shoes, aquele artigo parece detonar de vez a OO (nem li). É isso? Tu concordas?

#23

Eu já tive que fazer documentação RUP para ASP clássico :evil: :evil: :evil:

Hoje eu penso da seguinte forma:

Existem duas maneiras (basicamente) de fazer um sistema.

A primeira é a clássica: o banco de dados é o meu pastor, soterd procedure não me faltará. Esse é o modelo do lozano, onde o importante é a estrutura do banco de dados. Isso funciona e é bem eficiente em muitoas casos.

A outra é uma abordagem OO. Aqui os objetos são o seu sistema. O banco de dados é só uma fotografia doe stado dos objetos no isntante atual (ou no passado, se histórico).

Na primeira abordagem você semrpe vai tender á modelar os seus objetos como structs burras, proque você está refletindo as tabelas do SGBD, que são assim.

Quando inicio alguma modelagem hoje eu tento simplesmente esquecer que existem bancos de dados. Enquanto modelando a camada de negócios, meus objetos são sempre eternos em memória, automaticamente salvos. Geralmente eu coloco a lógica que “sabe” quando é hora de persistir na camada de aplicação, isso é ruim mas pelo menos a camada de negócios é livre para fazer o que tem que fazer.

Para persistir objetos, é relativamente simples (não necessariamente bonito ou fácil) seguir um prático idioma: Faça seus clientes conhecerem Interfaces de negócio apenas.

Vamos lá, meu clássico exemplo:


interface Usuario{
public boolean auteticar(String senha);
public String getLogin();
public void setSenha(String senha);
}

class UsuarioDeVerdade implements Usuario{
 private String senha;
 private String login;

 public String getSenha(){...}
}

O que se passa aqui?

Eu quero que os clientes possam apenas alterar a senha (sem saber o conteúdo anterior) ou compará-la com outra string. A interface usuario me oferece esses serviços. Ah, esqueça o noem horrivel da classe :stuck_out_tongue:

Para persistir meus Usuarios, eu vou precisar saber a senha para colcoar no SGBD.

Uma solução é uma fábrica de usuários:

class UsuafioFactory{

public Usuario novoUsuario(String login){
 UsuarioDeVerdade u = new UsuarioDeVerdade(login);
 return u;
}

}

E deixe seu DAO 9ou coisa que o valha) conehcer a implementação do usuário, apra que pegue os campos “escondidos” como senha.

É a melhor solução? Provavelmente não. É bonito? Definitivamente não. Funciona? Comigo tem funcionado.

Alguém tem em algo melhor pra propôr?

#24

Sim :twisted:

Não, mas oc ara tem bons argumentos e eu adoro uma discussão :slight_smile:

#25

Gostei dessa ideia do phillipi.
Expor somente a interface é bem legal.
O ideal seria que o código que chamasse a classe não precisasse chamar o método de persistencia nunca.

Mas como fazer isso ?

#26

Usando Container Managed Persistance, vulgo CMP. :lol:
Serio, sem um container só usando artificios feito AOP para ficar transparente.

#27

É verdade cara.
Para não chamar o método de persistencia só com container mesmo.

Ai o pessoal endoida !

#28

Ou proxies :smiley:

#29

Como é isso ?

#30

[quote=pcalcado]
Hoje eu penso da seguinte forma:

Existem duas maneiras (basicamente) de fazer um sistema.

A primeira é a clássica: o banco de dados é o meu pastor, soterd procedure não me faltará. Esse é o modelo do lozano, onde o importante é a estrutura do banco de dados. Isso funciona e é bem eficiente em muitoas casos.

A outra é uma abordagem OO. Aqui os objetos são o seu sistema. O banco de dados é só uma fotografia doe stado dos objetos no isntante atual (ou no passado, se histórico).

Na primeira abordagem você semrpe vai tender á modelar os seus objetos como structs burras, proque você está refletindo as tabelas do SGBD, que são assim.[/quote]

Um pequeno comentario. Com o uso do Hibernate o cara nota na hora quem faz o uso da primeira abordagem ou a segunda.

Sistema baseado no banco, sempre existe um ER e quando se altera o banco sai todo mundo correndo pra corrigir as classes, mapeamento, etc.
Sistema baseado no modelo de objetos. Pessoal altera as classes, roda uma taskzinha do Ant e o Hibernate ja atualiza a estrutura do banco.

]['s

#31

Mas, se for usar, faça-o com cuidado, pois proxies são lentos para instanciar, como o louds me avisou uma vez.

#32

[quote=pcalcado]interface Usuario…
class UsuarioDeVerdade implements Usuario…
[/quote]

Shoes, me perdoe não consegui entender a necessidade de uma interface. Por que haveriam diferentes implementações de usuário? UsuarioDeVerdade, UsuarioChato, UsuarioMentiroso etc??

E sobre “a hora certa” para persistir, essa é uma parada sinistra. Decidir em que momentos deve-se sincronizar com o BD. Por exemplo, ao obter as vendas do mês atual a partir de um List de vendas que é propriedade de um cliente, os dados podem estar desatualizados. No entanto fazer um select a cada chamada torna meio sem sentido guardar uma lista de vendas na memória (se toda vez que você precisa de algo você “selecta” em vez de pegar na propriedade) além de criar uma sobrecarga (acesso a disco). É outro dilema.

Fora o lance da interface que não entendi, o fato de vocês terem dito que não tem nada de “gordo” em objetos inteligentes já me refresca a cabeça um pouco.

[quote=LIPE]- o que diabos é a “identidade” do banco, e onde ela se perde? :smiley:

  • por que uma classe que tem atributos e métodos como qualquer outra classe dificulta reuso? E ela se acopla a quê?
  • falou sobre “divisão de responsabilidades”. Como já foi discutido em alguns tópicos aqui, descobrimos que é possível ter persistência e objeto de negócio convivendo em paz de algumas maneiras, portanto onde reside o problema?

ps.: estou perguntando na boa cara \o/[/quote]

Open my mind please :slight_smile:

  1. É o papel na novelinha:
    • Olá eu sou o BD, eu sou burro!!!
    • Olá eu sou o programador, vou te dar o papel de classe de dados!!

Eu disse que perde a identidade porque é como se o BD merecesse uma representação fiel na forma de classes de dados

  1. Por que podem haver casos (e me parece razoável) em que uma mesma informação pode ter várias lógicas. Imagine um banco que serve de base para várias aplicações cada uma fazendo coisas diferentes, a mesma informação em contextos diferentes. Então embutir lógica a uma informação indica que ela é dependente da mesma, quando na verdade ela existe por si só e pode ser usada de várias formas. Os dados que são coisas bem caracterizadas se acoplam a códigos (lógica) que ao tentar reutilizar em outro contexto não me vão ser necessários.

  2. Cada classe deve procurar preocupar-se com apenas uma coisa, e classes de dados devem preocupar-se apenas em representar os dados, de uma maneira consistente (validações, integridade referencial etc.). O que serão feitos com esses dados são outras coisas.

Em resumo o que o Shoes disse na primeira visão “banco-de-dática”, é como se o BD fosse um cara sinistro que consegue convencer o programados a dar-lhe papel de estrela (ser representado nas classes de dados). Na segunda visão o BD é apenas um figurante, um auxiliar que faz a persistência das verdadeiras estrelas, os objetos.

É um dilema entre uma visão mais concreta, onde o BD é relevante na modelagem, e uma visão mais abstraída, onde o BD é só um detalhe.

Humm… e então?

#33

Não criticando a ideia do Shoes que é muito boa
Mas concordo renato3110.
O BD não deve ser coadjuvante mais sim autor principal.

Cara esses negos de prevalayer e puristas OO metem o pau no BD.
Mas os dados valem mais do que o sistema.

Isso que eu penso.
O pesou tem sua aplicação totalmente orientada aos dados e quer tentar fugir disto.
As proprias funcionalidades da APP dependem do BD como
ordenção, paginação, exclusão em lote, atualização em lote.
As próprias interfaces se baseam no modela relacional.
Aquelas textbox com pesquisa, etc.

Enquanto o modelo relacional reinar fica difícil representa-lo como OO.
No outro tópico agente tá quase fazendo uma conferencia para resolver o problema dos atributos privados.

#34

renato, sua explicação da pergunta 2 não fez o menor sentido cara @.@ reuso não é poder dar um ctrl+c ctrl+v no seu PessoaISNPO( I Serve no Purpose Object ), que não passa de um monte de getters e setters e enfiá-lo em outro projeto. Falou sobre validação dentro da classe de dados (ISNPO), mas isso entra em conflito sobre o que você falou sobre a lógica mudar em cada contexto/aplicação.

E colocar os dados onde eles vão ser usados não é acoplamento, é bom senso. Não fazendo assim, no final das contas terá uma classe que, estranhamento, gasta 4/5 de suas linhas chamando gets e sets sendo que seria muito mais simples (o objetivo da coisa toda) ter as duas coisas, dados e comportamento, no mesmo lugar. E por “mesmo lugar”, entenda que há várias implementações possíveis.

Sobre a pergunta 3, entendi que você trata Dados como um Objeto e Comportamento como um outro Objeto. Agora me diz o que os Dados fazem sem o Comportamento e vice-versa.

E jprogrammer, com uma boa modelagem (o que estamos tentando concluir aqui) isso que falou não é verdadeiro. Penso que o objetivo, como o Shoes tanto fala, é abstrair completamente o banco de dados. Não importa onde nem se os dados estão sendo persistidos em algum lugar. Essas funcionalidades que você falou podem ser perfeitamente implementadas com outras tecnologias que não um sgbd.
Não entendi o que quis dizer com " As próprias interfaces se baseam no modela relacional", muito menos o seu exemplo. Acha que não existe uma textbox para pesquisa ao usar Prevayler, por exemplo?

Cara, a dificuldade é como modelar a persistência dos dados, e não o banco de dados relacional. Onde colocar o método create(), retrieve(), update() e delete(). Insisto que experimente o Hibernate.

#35

Esse é um pensamento procedural, ai é mais facil fazer as coisas com PL/SQL ou PLps/SQL do que com Java. Agora se tu quer continuar com Java e bom mudar o pensamento senao perde o sentido. E falando em objetos como o mesmo objeto pode ser manipulado de forma diferente em contexto diferente?
Quer dizer que o controle remoto da tua casa (que é um objeto) uma hora tu aperta nos botoes pra ele funciona, mas em outro contexto tu joga ele na parede?

Desculpa Renato, mas a impressao que ficou é que tu quer fazer uma salada de fruta com os conceitos e linguagem.

]['s

#36

Ta certo. Ai eu faco um sistema de banco, faco tudo errado. O sistema calcula errado os depositos, retiradas, juros, etc, fica uma coisa linda neh…o banco te salva nessa?

[quote=jprogrammer]O pesou tem sua aplicação totalmente orientada aos dados e quer tentar fugir disto.
As proprias funcionalidades da APP dependem do BD como
ordenção, paginação, exclusão em lote, atualização em lote.
As próprias interfaces se baseam no modela relacional.
Aquelas textbox com pesquisa, etc.[/quote]

Mas nem todoas aplicacao sao iguais as que tu desenvolve.
Se tu desevolve so aplicacoes CRUD baseadas no banco e nas tabelas, usa outra ferramenta, quem sabe o Forms da Oracle que te quebra um galhao nessa hora.

Eu nao acho tao complicado assim, mas claro pra isso precisa querer. Quando eu comecei com Java tambem tinha esse pensamento que o banco de dados era tudo, joga la dentro que ele resolve. Hoje tenho uma opiniao totalmente contraria (e olha que eu era quase um DBA).

#37

Olá,

Você não entendeu, a implementação não é diferente. Só vai existir uma implementaçãod e usuario, a grande questão é uma limitação da tecnologia.

Para persistir a senha desse Usuario, eu vou precisar acessar o valor desse atributo (seja com um get ou outro treco) certo?

Mas e se eu não quiser expôr minha senha a outras classes? Na verdade, segundo mei domínio, a senha não deveria ser exposta a ninguém, é valor de somente escrita e comparação. Como eu persistiria algo assim com a tecnologia que temos hoje?

A idéia é criarmos uma interface que exponha as operações “de negócio” do objeto e façamos quem precisa conhecer mais sobre o objeto (precisa, proe xemplo, pegar o valor da senha) utilizar uma interface mais ampla. Nomes aos bois: A lógica de negócio usaria a interface usuario, o DAO (argh) usaria a implementação. Assim você diminui o “vazamento de informações” sobre, por exemplo, a senha.

Quanto aos dados, jprogrammer, sim, eles são improtantes, mas o ponto do Fábio é certo.

Os dados são or esutlado do seu processamento, num sistema OO seus dados não ficam em tabelas, eles ficam em objetos. As tabelas são apenas um meio de persistir, como poderia ser XML, serialização, CSV, txt, cartão perfurado…qualquer coisa. É claro que um SGBD oferece ferramentas muito legais, mas ele é só uma opção.

Basear um sistema OO no formato de tabelas (exceto sistemas legados) é besteira, baseie as suas tabelas no seu domínio, não o contrário.

#38

Eu posso até pensar assim.
O problema é que a cultura de TI é muito baseada no BD.

Não sei o caso de vocês, mas a primeira coisa que o pessoal quer saber sobre o sistema é base de dados para depois poderem fazerem relatórios, bacalhaus, coisas por fora.

Os analista sempre perguntam : O que aquela select está retornando ?
Nunca perguntam: o que aquele método retorna.

Fica difícil nestes casos.

É o problema da metodologoia “híbrida”.
Meia OO - Meia Estruturada/Relacional.

#39

jprogrammer, nao entendi o seu objetivo depois de toda essa discussao. Voce quer fazer a coisa decente, ou vc quer reclamar pq a “cultura de TI” nao faz a coisa do jeito que a gente queria, baixar a cabeca e voltar pro seu DAO? Vamos tentar ser mais construtivos, por favor?

#40

Concordo.
Não por isso que vamos fazer as coisas erradas.
É apenas uma observação.

É claro que eu seguirei ou tentarei seguir o OO até o fim.
Procuro aprender cada vez mais.