Classes de dados e classes de lógica

Conceitualmente isso está errado.
Como vc disse pelo conceito OO devemos ter dados e operações juntos.

Mas funcionalmente isso é ideal na minha humilde maneira de ver.
Você tem separação das classes persistentes que representam as entidades e os processos.

Entre o conceitual e o funcional eu escolho o meio-termo.
E essa declaração me parece ter bom censo.
Eu adotaria…

Cara, você falou de acoplamento fraco, mas depois também falou:

No fim das contas você vai se encontrar fazendo isso aqui

public class FuncionarioManager {
    public FuncionarioManager( Funcionario func ) {
           func.getX();
           func.getY();
           func.getW();
           func.getGet();
           func.getGetter();

           func.setX( x );
           func.setY( y );
           func.setW( w );
           func.setSet( set );
           func.setSetter( setter );
   }
}

Por que não coloca tudo no mesmo lugar de uma vez? Se falar que é para aliviar a carga da rede, vou postar uma imagem aterradora.

O grande problema da modelagem é que temos que amarrar nossa lógica OO com o modelo relacional.

Não tem jeito gente. O modelo realcional é a melhor maneira de persistencia existente hoje.
Querendo ou não temos que adaptar nosso modelo OO para o relacional.
Por motivo de desempenho, reaproveitamento da lógica de dados, funcionalidades do sistema.

Esse é o grande problema ao meu ver. Sempre a gente tem que fazer alguma gambiarra.
Nós pensamos ainda com pensamento relacional, não adianta fugir.
Sempre iremos exergar “select * from…” ao inves de objeto.fazer();

Oi,

Eu já li coisas boas e ruins do lozano, tenho até o livrinho dele em java com GNU/Linux (despretencioso e bonzinho), mas realmente essa afirmação é mais um motivo para eu não comprar a Java Magazine este mês.

Vou dividir isso em duas coisas. primeiro: você precisa de um domínio de aplicação? Sim, essa é uma pergunta séria. Você pode não precisar e muitos aqui não precisam para muitas das coisas que fazem. Avaliar isso é difícil, se você chegou à conclusão que:

• Não vai ter que dar manutenção
• A aplicação é mais que simples, é idiota, do tipo tira e põe no SGBD
• Tempo escasso

Faça como o Lozano sugeriu.

Se você está fazendo algo mais complxo, ou algo que vá evoluir, considere construir um projeto dividido em camadas e com um domínio bem projetado.

O domínio compreende objetos que representam entidades e valores no seu sistema, temos nossa classe Venda, por exemplo.

Acima da camada de domínio existe uma camada de aplicação. Nessa camada nós pdoeríamos oferecer, por exemplo, uma classe GerenciadorVendas (utilizando um Service Layer) com um método registrarVenda(). Este método é extremamente magro e só envia uma mensagem para os obejtos de negócio, criando um objeto venda, por exemplo.

Se eu rpecisar de uma funcionaldiade de relatórios, eu pdoeria criar uma classe GerenciadorRelatorio com método gerarRelatorioVendasMes(Mes mes) que estimulasse os objetos de negócio nesse sentido.

A camada de aplicação é muito importante para estimular os objetos de negócio, mas as regras de negócio estão nestes objetos. Essas classe sim não têm estado, mas as classes de negócio têm estado sim (é claro que existem casos onde não teriam, ams de uma maneira geral sim, teriam).

O que o Lozano propõe, me parece, é pura e simplesmente programação estruturada. Eu tenho minha “classe de informação”:

class Venda{
 private String codigo;
 private double valor;
 private Date data;
 private Cliente cliente;
 private Collection itens;
 //get/set...
}

E minha classe de “processo de negócio”:

public void registrarVenda(String codigo, double valor, Date data){
 Venda venda = new Venda();
 venda.setCodigo(codigo);
 venda.setValor(valor);
 venda.setData(data);
 cliente.addVenda(venda);
 venda.setCliente(cliente);
 ...
 persistenciaQualquer.salvar(venda);
 persistenciaQualquer.salvar(cliente);
}

public void cancelarVenda(Venda v, Cliente c){

 c.listarVendas.remove(v);
 persistenciaQualquer.deletar(venda);
 persistenciaQualquer.salvar(cliente);
}

Agora me digam: qual a diferença entre isso e programação estruturada?

Alguém sabe o mail do lozano? Ele pdoe se interessar pela discussão…

jprogrammer no seu outro tópico foram dadas sugestões para resolver este problema.

Não entendo por que vocês acham que é necessária uma classe só para persistência. A merda reside em como popular o objeto, mas este precisa de atributos não importa qual o mecanismo de persistência.

jprogrammer:

O grande problema da modelagem é que temos que amarrar nossa lógica OO com o modelo relacional.
…
Esse é o grande problema ao meu ver. Sempre a gente tem que fazer alguma gambiarra.
Nós pensamos ainda com pensamento relacional, não adianta fugir.
Sempre iremos exergar “select * from…” ao inves de objeto.fazer();

Mapeamento Objeto-Relacional é uma droga, mas o problema não é tão grande assim. De repente esse texto (ou outro desse site/livro) te ajuda.

O grande mal do mapeamento é que você vait er que expôr seu estado para que seja persistido. Existem diversas formas de amenizar o rpoblema (como usar múltiplas interfaces para múltiplos clientes), mas essa limitação não afeta o princípio geral das coisas, de que um objeto deve ter estado e comportamento.

Nova recomendação de leitura do Shoes:

Eu estou convencido e não tenho mais dúvidas enquanto isso.
É apenas uma observação pessoal de que é difícil modelar OO se baseando na estruturada.
É uma coisa de cultura.
É difícil largar os velhos conceitos.
Mas muitas vezes é a própria teconologia que nos limita…

Olá,

Nós pensamos ainda com pensamento relacional, não adianta fugir.
Sempre iremos exergar “select * from…” ao inves de objeto.fazer();

Estou tentando evitar isto, mas o problema de performance, em ter que instanciar classe por classe (via construtor-negócio -> contrutor-banco -> contrutor-negócio ) está me forçando a pensar estruturado novamente.

Márcio

Lipe posta aquela imagem porque realmente eu fico pensando se “objetos inteligentes” são mais “gordos”, mas custosos de enviar pela rede ou mesmo instanciar. Ainda não tirei nenhuma conclusão, estou meio confuso ainda.

Na verdade, é o contrário. objetos magros são mais caros de passar, proque geralmente um objeto magro tem associações mil com um onte de gente, e você vai precisar utilizar estas associações. Cada vez que você precisa, você faz uma chamada RPC bem cara para executar uma coisa a toa, por isso é mais prático embrulhar tudo e mandar de uma vez na rede

Estou completamente errado ou a sugestão do Lozano é que devemos utilizar Anemic Domain Model? http://www.martinfowler.com/bliki/AnemicDomainModel.html

[]'s
Marco Campêlo

marcioa1
Apesar de estar convencido sobre os benefícios OO.
Eu também penso nisso diariamente…
Não sei se não se estão nos vendendo modismos…
Quando vejo aplicações estruturadas super robustas e escaláveis fico com uma saudade.

pcalcado:

Alguém sabe o mail do lozano? Ele pdoe se interessar pela discussão…

[email removido]

[]'s
Marco Campêlo

Ah Márcio cê taí! Nem continuou naquele tópico de performance hein? Parecia que cada instanciação executava um select diferente na mesma tabela…Posta lá, responde!!

Email:

Phillip Calçado to fernando
More options 11:02 am (34 minutes ago)
Olá, Fernando,

Estamos discutindo no GUJ um texto seu na Java Magazine deste mês
(creio). Se quiser dar uma olhada e responder, seria muito bom para
trocarmos experiências.

O thread está em:

http://www.guj.com.br/posts/list/23735.java

[]s

–
Phillip Calçado
ICQ: 1110nine38six5
M$N: [email removido]
Y!: [email removido]
http://www.jablo.com.br/blogs/page/pcalcado
http://www.jroller.com/page/pcalcado
Crux Sacra Sit Mihi Lux

Você pediu pela imagem: medo

Ainda não consigo entender a diferença entre ter uma classe com dados e lógica e ter duas classes, sendo que uma fica fazendo get e set pra todo lado. Alguém sabe me explicar a vantagem da segunda maneira?

Tente isso aqui.

Esse cara é corajoso !!!

O problema é como um ex professor que trabalhava em uma dessas consultorias bam-bam-bam falava tem gente que exige a metodologia RUP, mas não sabe o que é RUP.
Eu quero RUP porque é bom.

Outra coisa que ele metia o pau era a metodologia “hibrida”.
meia-estruturada meia-OO.
É o que o pessoal anda fazendo.

O artigo do Lozano tem uns três meses.

O problema é que fazendo a parada ficar mais OO, mais intuitiva, parece que a “identidade” do banco fica meio perdida. Parece que dificulta reuso e divisão de responsabilidades, gera acoplamento. Por outro lado, as classes ficam meio “soltas”, menos coesas e intuitivas. É um dilema!

Uma coisa interessante seria criar uma classe de dados e extendê-la com lógica de negócio:

class DadosCliente {
    String nome, endereco;
    int idade;
}

class Cliente extends DadosCliente {

    List<Venda> vendas; 

    public List<Venda> getVendas(int ano) {
        // tralálá
        return vendasNoAno;
    }

    public boolean isChato() {
        return this.mediaLigacoesSACNoMes() > 4
    }

}

Desse modo eu poderia reutilizar a classe de dados com outra lógica, criando uma nova sub-classe. O que acham?

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?
• 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/

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

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

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?

Sim :twisted:

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

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 ?

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

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

Ai o pessoal endoida !

Ou proxies

Como é isso ?

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.

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

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

pcalcado:

interface Usuario…
class UsuarioDeVerdade implements Usuario…

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.

LIPE:

- o que diabos é a “identidade” do banco, e onde ela se perde?

• 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/

Open my mind please

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

2. 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.

3. 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?

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.

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.

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

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?

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.

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).

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.

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.

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?

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.

É o que falei no final, modelar o banco ou deixá-lo como coadjuvante. É uma questão de decisão. Na verdade acho que esse caso de reuso que tentei explicar não é comum acontecer, acho que são mais para sistemas separados que compartilham uma mesma base de dados.

Imagine a base de dados dos micros da empresa, só que não existe apenas um sistema que faz tudo, mas vários cada um especializado em certa área, mas compartilhando o mesmo BD. Um usa para controle de ordens de serviço, outro para o próprio gerenciamento de micros, outro para chamados técnicos. Pra mim faria sentido definir Micro como um simples micro, não um micro que conhece OS, conhece chamados, conhece impressoras. Ficaria estranho reusar isso ou reescrever os atributos em cada sistema. Mas como disse acho que é raro esse “compartilhamento de BD”.

Uma coisa que seria uma solução para unir os dois jeitos de pensar seria definir uma classe genérica Micro e extendê-la de maneira apropriada a cada sistema. O que acha Lipe?

Como disse, se estes dados podem ser caracterizados como uma entidade existente por si só, e principalmente (o que como disse acima parece ser raro) podem ser utilizados de várias maneiras (independente de lógica), acho que vale a pena modelá-los como uma entidade separada (classe de dados, struct, bean etc.)

Depende. Como disse:

2) Os dados representam informações de estado ou suporte a uma classe de negócios (não especificamente de aplicações de banco de dados), ou seja, elas só têm sentido se associadas a uma determinada lógica, e não como representantes de uma entidade de informação existente por si só:

Neste caso não vou criar uma classe separada com os dados, vou colocá-los juntos com a classe de lógica, pois os dados são uma característica, uma propriedade da classe.

:shock: Não importa nem se seu salário ir embora junto com a memória RAM ?? :mrgreen:

Isso é uma parada sinistra. Assunto de novo tópico. Alguém conhece algum antigo que já tenha discutido isso? Se valer a pena, qualquer dia alguém podia abrir um…

Lipe, me parece que o melhor jeito, caso se queira ser “legalzinho” com o BD, caso se queira modelá-lo, no entanto “OOzando” - sem deboche, “melhorando” - seria criar as classes de dados e quando criar as classes de lógica, em vez de ser separadas das de dados, estendê-las. O que acha?

No livro que eu citei (sugestão do cv, BTW), o Evans fala sobre isso.

Você pdoe até separar seus objetos dessa maneira, ams qual a real vantagem?

No final das contas, você acaba com um domínio de aplicação artifical desnecessariamente. O objeto individual do mundo real é dividido em N objetos no seu sistema, o que causa uma confusão emntal enorme, além do acoplamento entre esses objetos ser tão grande que eles deveriam claramente ser um objeto só.

A idéia em trabalhar com objetos é justamente manter as coisas simples e coesas.

Ahhhhhhhh!!! Era sobre isso que estava pensando!! Esse problema se chama permissões de segurança. O Windows tem, as classes ainda não. Agora entendo porque você diz que é feio mas funciona Realmente uma interface para cada aspecto de segurança de uma classe pode se tornar esquisito caso hajam muitos.

Muito interessante essa observação…

jprogrammer:

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

Na verdade acho que o problema é a coexistência das duas, quando precisam interoperar, onde OO é o lado mais fraco.

Alguém já desenvolveu alguma solução de BI em java ?
Como fica isso orientado a objetos ?
Esse tipo de aplicação é muito dependente do base de dados (Data Warehouse).

Sei que o java suporte inúmeros recursos OLAP, etc.
Mas isso orientado a objetos.
Nesse tipo de aplicação a lógica de dados é bem mais forte que a lógica de negócios.
Compensa fazer isso OO ?

Não exatamente segurança, ams sim abstração. Os dados estão lá, se o cara quiser manipular ele vai dar um jeito, nem que seja manipulando byutecode. O que você precisa é não fazer seu cliente se preocupar com o que não é da conta dele

HUhahauahuahauhauahuah :lol:

Exatamente!

Na verdade, estou tentando me livrar dela!

jprogrammer:

Alguém já desenvolveu alguma solução de BI em java ?
Como fica isso orientado a objetos ?
Esse tipo de aplicação é muito dependente do base de dados (Data Warehouse).

Sei que o java suporte inúmeros recursos OLAP, etc.
Mas isso orientado a objetos.
Nesse tipo de aplicação a lógica de dados é bem mais forte que a lógica de negócios.
Compensa fazer isso OO ?

Nao seria melhor um outro post, pra nao misturar os assuntos?

Mas ja respondendo, eu nunca usei e nem fiz algo do genero com Java, mas se nao me engano tem uma JSR nesse sentido (parece que a Oracle é uma das Owner).

]['s

pcalcado:

Email:

Phillip Calçado to fernando
More options 11:02 am (34 minutes ago)
Olá, Fernando,

Estamos discutindo no GUJ um texto seu na Java Magazine deste mês
(creio). Se quiser dar uma olhada e responder, seria muito bom para
trocarmos experiências.

O thread está em:

http://www.guj.com.br/posts/list/23735.java

[]s

–
Phillip Calçado
ICQ: 1110nine38six5
M$N: [email removido]
Y!: [email removido]
http://www.jablo.com.br/blogs/page/pcalcado
http://www.jroller.com/page/pcalcado
Crux Sacra Sit Mihi Lux

Já que o Lozano não apareceu por aqui para nos explicar melhor o que ele quis dizer no artigo, quem se candidata a mandar uma carta para a revista questionando o artigo?

[]'s
Marco Campêlo

mcampelo:

Já que o Lozano não apareceu por aqui para nos explicar melhor o que ele quis dizer no artigo, quem se candidata a mandar uma carta para a revista questionando o artigo?

[]'s
Marco Campêlo

A tartaruga do DQO sempre pode mandar umas cartinhas…

louds:

A tartaruga do DQO sempre pode mandar umas cartinhas…

Clotilde,

cadê você?

[]'s
Marco Campêlo

pcalcado:

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?

Shoes, tem outro exemplo? Nesse caso da senha acho que o ideal é guardar o hash da mesma.

Mas aí “magro” pra você quer dizer com menos campos, não? Eu estou falando de métodos, objetos com métodos + dados. Tem certeza que transferir na rede ou criar um objeto com 10 campos e 200 métodos é a mesma coisa que um objeto apenas com os 10 campos?

mcampelo:

Já que o Lozano não apareceu por aqui para nos explicar melhor o que ele quis dizer no artigo, quem se candidata a mandar uma carta para a revista questionando o artigo?

Até pensei nisso. Se ninguém mandar talvez eu mande. Um outro dia tinha um cara dizendo que software livre no fundo é exatamente a mesma coisa que open source, e que todo open source é software livre. Esquisito…

Putz, adorei o tópico. Vcs não sabem o quanto estes conceitos tem dado um verdadeiro nó na minha cabeça e admito depois de muitos anos trabalhando somente procedural que passar para um modelo OO não é fácil. E o grande nó tem sido a separação dados e regras de negócio. Ainda não consegui entender bem o conceito estando ainda amarrado a exatamente o que o Jprogrammer colocou.

Shoes, desculpe-me se a pergunta for redundante, mas o livro que vc sugeriu trata exatamente da essência deste tópico?

Ok, vamos pensar… já te respondo.

Acho que me confundi aqui.

Determinados objetos possuem uma relação de agregação com outros. Na verdade, eles são significativos apenas com um conjunto de outros objetos, e precisam destes outros objetos o tempo todo.

Se você passar apenas a “raiz” dessa árvore de objetos" para um nó remoto, o que vai acotnecer é que você vai ter diversas chamadas RPC para os objetos agregados desta, porque este objetonão consegue fazer nada sozinho.

Um DTO (aimeuzahldenovonao!) é um pacotão de objetos que vão ser necessários ao cliente remoto, com a finaldiade de evitar tantas chamadas RPC minúsculas e caras.

No finald as contas vai ser muito mais jogo você passar um grande e gordo objeto quase independente do que objetos magrinhos que vão precisar se comunicar na rede o tempo todo.

TU ta falando deste livro?

Bom, digamos bem sucinto que este livro trata de como criar os modelo de dominio mais “rico” nao separando logica de negocio dos dados.
Tem mais info no site deles da uma olhada por la.

www.domaindrivendesign.org

]['s

guariba:

Shoes, desculpe-me se a pergunta for redundante, mas o livro que vc sugeriu trata exatamente da essência deste tópico?

Esse livro mostra padrões simples (estilo Craig Larman) para aplicar um bom projeto de domínio no seu sistema 9com exemplo em Java).

Ele vai te dar boas idéias sobre como e porque você deve modelar as entidades em classes e agregações, e te encher de padrões para fazer isso. Muitos exemplo, explicações e causos.

Se você quer aprender teoria OO, esse livro não é indicado, ele é bem prático para quem já tem um bom conhecimento (que a maioria dos programadores Java que conheço não tem). O lviro do Craig pode ser um bom início para ele.

Obrigado.

Usando este modelo que o Shoes mostrou. Eu até ja usei ele algumas vezes, mas nunca me atentei pra um detalhe e agora fiquei com uma duvida.

Supondo que eu tenho as seguintes Interfaces.

public interface Usuario {
  void setLogin(String login);

  String getLogin();

  boolean usuarioValido();
}

public interface UsuarioCompleto extends Usuario {
  //TO-DO Aqui todos get e set e mais as manipulacoes necessarias para o User.
}

public class UsuarioImpl implements UsuarioCompleto {
//TO-DO Implementacao de todos os metodos da Interface.
}

Supondo que eu queira mandar somente login e senha para minha view eu faria o seguinte.

...
Usuario usuario = usuarioImpl;
...

E enviaria este "usuario" para minha view, logo estarei disponibilizando para minha view somente os metodos da Interface Usuario.
Minha duvida: por mais que meus outros attributos estejam preenchidos eles serao trafegados pela rede ou somente o que compoe a Interface Usuario?

Nunca pensei em fazer um teste assim.

Alguem?

]['s

Tem um cast a toa no seu exemplo (ja que UsuarioImpl implementa Usuario, vc nao precisa do cast), e sim, tudo vai ser trafegado, pq a JVM nao tem inteligencia pra saber que ela pode serializar so metade do objeto.

Arrumado tks. Pois é seria pedir demais pra VM neh.

Opa, segurem suas cartas!

pcalcado:

Determinados objetos possuem uma relação de agregação com outros. Na verdade, eles são significativos apenas com um conjunto de outros objetos, e precisam destes outros objetos o tempo todo.

Se você passar apenas a “raiz” dessa árvore de objetos" para um nó remoto, o que vai acotnecer é que você vai ter diversas chamadas RPC para os objetos agregados desta, porque este objetonão consegue fazer nada sozinho.

Um DTO (aimeuzahldenovonao!) é um pacotão de objetos que vão ser necessários ao cliente remoto, com a finaldiade de evitar tantas chamadas RPC minúsculas e caras.

No finald as contas vai ser muito mais jogo você passar um grande e gordo objeto quase independente do que objetos magrinhos que vão precisar se comunicar na rede o tempo todo.

Humm… o que você quer dizer com “passar” o objeto? Passar a referência (o objeto é uma representação remota)?
Ou passar o objeto em si? É disso que estou falando, acho que não me entendeu, veja:

// classe de dados

class SalaCinema {
    Cinema cinema;
    List<Pessoa> pessoas;
    Filme filme;
}

// classe de dados + logica

class PowerSalaCinema extends SalaCinema {

    public boolean isLegal() {
        return !(cinema instanceof ArtFilms);
    }

    public void limpar() {
        for each p in pessoas // assim ficava legal...
            if (p.isPorca()) {
                kickAss(p);
                p.limpaSujeira(this);
            }
        }
    }

    public Dinheiro passarFilme() {
        return filme.passar();
    }

    // etc...

}

O que eu perguntei é se criar mil instâncias da segunda classe dá no mesmo que da primeira. Sacaste? E também, se eu passar mil objetos da primeira classe (o objeto como valor, não uma referência remota) seria mais enxuto que os da segunda?? Entendestes?

Oi,

Acho que entendi agora. Faça o teste: serialize dois objetos desta classe. Note que o bloco de lógica é um só, para mil e uma instâncias, um só bloco lógico. Sinceramente, você dificilmente vai ter problemas se utilizar pass-by-copy.

Quanto ao exemplo, pensei em algo mais acadêmico agora na aula do McDonald’s:

interface Livro{

public void avancarPagina();
public void recuarPagina();
oublic void abrir();
public void fechar();
public Pagina getPagina();

}

Define um livro (duh!) sem se preocupar com implementação. Posso ler ele a vontade assim, correto?

Implementação:

class Brochura implements Livro{
private List paginas = new ArrayList();

public List getPaginas();
public void addPagina(Pagina p){...}
public void removerPagina(Pagina p){...}

/*
métodos da interface...
*/


}

Imagina o estrago que alguém pode fazer com a lista que mantêm as páginas saindo de um

public List getPaginas(){
 return paginas;
}

Mas para, por exemplo, persisitr um Livro, eu vou precisar saber mais o que a Interface me diz. A Interface não me dá detalhes de implementação, mas eu consigo pensar duas situações onde você vai precisar destes detalhes:

• Criação (por uma Factory ou não)
• Persistência

São dois casos isolados e, principalmente, são dois casos que não têm muito a ver com o su domínio, não estão mapeando nada no seu sistema, são apenas infra-estrutura e limitações. Para estas classes você pode utilizar a implementação diretamente.

Ainda sobre o Livro do Evans, eu diria que você tem algumas opções para começar a entender OO: uma delas é ler a bilbiografia que recomendei outro dia, uma outra é ler um livro bom de OO e depois ler o Evans. Ele compila o conhecimento espalhado por vários outros volumes de maneira bem prática, tirando a gordura que você não vai usar no dia a dia (mas que é sim importante, apesar de que pelo menos se as pessoas se preocuparem em saber o básico já está melhor que hoje em dia!).

Oi guariba.
O conceito que eu estava colocando se refere as limitações tecnológicas e conceituais que ainda temos para implementar OO.
Temos que nos perocupar com várias coias que não fazem parte da modelagem propriamente dita:
Persistencia, Tráfico de rede, funcionalidades.

E conceituais porque muitos analistas ainda pensam proceduralmente mesmo quando modelam OO.

pcalcado:

Oi,

Acho que entendi agora. Faça o teste: serialize dois objetos desta classe. Note que o bloco de lógica é um só, para mil e uma instâncias, um só bloco lógico.

Ah isso que estava pensando. Então quando 200 objetos são transferidos na rede, a definição dos métodos é copiada uma única vez? A JVM é “inteligente” nesse ponto?

Agora ficou melhor. É como se cada interface fosse um aspecto diferente da mesma classe. Creio que seja meio massante (apesar de funcional) trabalhar assim, não? Imagina que o livro seja um pouco mais complexo, e que os “aspectos” a serem expostos, mais variantes? Criar (e gerenciar) trocentas interfaces pra isso deve ser bem chato hein?

Aquela lista de dez livros de OO? Tenho ela no meu favoritos

Alguma novidade por aqui? Qual a conclusão?

A conclusão é o seguinte, pelo menos na minha opinião. Qual é a idéia do desenvolvimento de sistemas? É resolver problemas de negócio. Para onde estamos caminhando? Para que as coisas fiquem cada dia mais simples, e o software fique cada dia mais próximo do negócio. O mundo perfeito seria se o próprio gerente comercial alterasse regras de negócio, integrasse dados, mudasse a sua organização sem a dependência de um time de TI para “implementar as coisas”. No mundo perfeito, o usuário tem controle sobre a informação sem a necessidade de nós, arquitetos, programadores, analistas, testers e etc…

A leitura do Eric Evans é super importante. Ter uma camada de negócio é super importante. A questão não é só sofrer de Anemic Domain Model, ou deixar regras de negócio espalhadas, ou trabalhar procedural. A questão é que uma camada de negócio é algo próximo do usuário. Suas classes possuem nome de conhecimento do usuário. As operações de uma entity podem ser compreendidas e fazem sentido ao negócio. É o software próximo do problema. O resto, as telas, façades, os webservices, a infra-estrutura são só complicações que o paradigma atual nos impõe. No futuro, o próprio gerente do negócio vai mudar o domain model, ou o seu processo, sem a necessidade do time de TI.

Imagino que no futuro vamos nos aproximar cada vez mais do mundo perfeito. A OO aproximou. Uma maneira de mapear objetos para a sua persistência também… SOA, MDA, BPM, tudo caminha para esse mundo perfeito (não quero entrar em discussão a respeito da MDA).

Espero ter contribuído com alguma coisa, mesmo sem ter respondido nada especificamente.

Caraca, tiraram o tópico da cova hein!

Taz, eu conversei com o lozano por e-mail e ele falou bastante coisa também, algum dia vou ver se publico porque tem que organizar aquilo lá.

Bom a conclusão que eu cheguei é que classes de lógica e classes de dados separadas é um troço esquisito

Há uns dez anos eu ouvi falar dessa história de o usuário criar seu próprio programa. Até agora não vi nada acontecer nesse sentido e sinceramente acho que estamos ultra distantes disso.

Não tinha visto que o tópico tinha ressurgido das cinzas

Já ví pessoas comuns fazendo sistemas departamentais em Access. Já ví gestores fazendo sistemas java com o antigo RRD (Rational Rapid Development). As ferramentas MDA* como o OptimalJ da Compuware também estão bem próximas disso. Ainda não é realidade. Como falei, é um futuro. Você não concorda que o mundo perfeito seria esse que “pintei”?

Além disso, como ainda estamos longe, um Domain Model, e principalmente, entities ricas em comportamento de negócio trazem outros benefícios:

• Menor necessidade de documentação do projeto
• O trabalho de análise é mais produtivo e focado
• Melhor separação de responsabilidades no time
• Mudanças são mais rápidas (menor necessidade de “rastreabilidade”)

Rodrigo,

faço minhas as suas palavras. Eu diria que a leitura do eric Evans é essencial.

Por outro lado, o que tenho visto no mercado é que desenvolvedores e projetos inteiros acabam por usar a arquitetura Orientada à Serviços (SOA) como desculpa para justificar um “anemic model” e, com ele, a velha abordagem de análise estruturada. Acho que SOA tem sido MUITO mal-interpretada. Os profissionais deveriam encarar SOA como mais uma ferramenta que tem suas vantagens e desvantagens e que é apropriada para resolver alguns tipos de problema. SOA não joga fora o paradigma OO. SOA é somente mais uma camada de abstração em relação ao que desenvolvemos/conhecemos até hoje sobre compenentes.

Não li todos os posts mas ja discuti muito esse assunto.

Existe um livro muito bom, chamado “Pojos in Action”. Ele explica e compara o domain model, com outros paradigmas de desenvolvimento, como os procedurais e outros.

Não existe um certo ou errado e acho que todos já sabem disso. O difícil é saber escolher o mais adequado pra cada situação, sendo q as vezes nem podemos fazer isso por imposições tecnológicas do tipo “não pode usar hibernate” hehe

quanto ao livro… deem uma olhada… muito bom mesmo!

O POJos in Action é bom, mas em duas sitções:

• Tenho pressa
• Já li Eric Evans e Martin Fowler

Ele msotra como implementar alguns conceitos de DDD utilizando tecnologias leves, bem legal mesmo, mas nem só de prática vive o programador.

pcalcado:

O POJos in Action é bom, mas em duas sitções:

• Tenho pressa
• Já li Eric Evans e Martin Fowler

Ele msotra como implementar alguns conceitos de DDD utilizando tecnologias leves, bem legal mesmo, mas nem só de prática vive o programador.

ou…

“eu quero apenas ter uma visao pratica sobre as diferentes formas de estruturar um sistema”

hehehehe 8)

mas vc esta certo… ele nao se aprofunda nos topicos… mas a serie “in action” é pra isso mesmo né

Galera vendo o tópico sobre classes persistentes e não persistentes(as de lógica de negócio).
Pensei que isso seria uma ótima prática, pois usando um private nos atributos da classe persistente geraria encapsulamento, fazendo com que o programa fique uma autêntica O.O. Pois na regra de O.O. jamais deve ser quebrado o encapsulamento…
Imagina um get e set nas classes persistentes e as classes não persistentes faz delegação/solicitação para realizar um set ou get nas persistentes. Que código organizado né?!

Segundo meus conhecimentos, se estiver errado me corrigem…

Vou pensar nesta idéia de classes persistentes e não persistentes daqui em diante…

Abraços a todos

Olá,

Não entendi muito bem o que você propôs. Classes não persistentes seriam as que contêm lógica e as persistente as que contêm dados?

pcalcado:

Olá,

Não entendi muito bem o que você propôs. Classes não persistentes seriam as que contêm lógica e as persistente as que contêm dados?

Isso mesmo, é que o olhando o tópico sobre: Classes de dados e classes de lógica

Veio logo em mente, utilizar uma classe que é persistente (acesso direto ao B.D.) ou seja, só faz get e set.
E uma não persistente(está só na memória RAM, não tem acesso direto ao B.D.) que só processa recebe dados do usuário.

exemplo:
classe “Cliente” realiza persistentência em tabela cliente

classe “TransacaoCliente” processa dados enviados por usuário, realiza consulta de dados fazendo uma solicitação a classe Cliente, assim como inserção e etc…

pelo que entendi essa é a idéia do tópico ou não?

Eu estou iniciando em JAVA.
Isso é uma boa prática não é?

abraços

Não, João, na verdade geralmente é uma péssima prática

O tópico discute exatamente isso, sobre a inexistência desta divisão num programa OO. Leia a discussão e siga as referências apra artigos para entender melhor.

Ok, valeu pela dica, vou verificar um pouco mais no fórum.
Mais porque não é recomendado???

Tirando o tópico da cova outra vez, aqui tá a conversa com o Lozano (ou parte dela, não lembro…)

Primeira coisa que ele já peca na resposta é afirmar que em “OO clássico”, usar herança é reutilização de código.

FL:

O estilo “clássico” de desenvolvimento OO super-valorisava a colocação de todo o comportamento
de um objeto nele mesmo e o uso de herança como forma de reutilizar código.

Não sei se este texto é da época, mas de qualquer forma:

Este ponto mostra alguns problemas. Primeiro eu precisaria de alguma
referência sobre “OO clássica” já que eu nunca vi nenhuma fonte com
credibilidade desvincular estado e comportamento do objeto, mesmo
porque isso não seria mais Orientação a Objetos e sim programação
procedural.

Segundo ponto é que -sendo o artigo de 2005- já existe tecnologia
suficiente para não misturar estes conceitos em Java há muito
tempo. Seria interessante um exemplo do porque isso seria um problema.

Camadas e Componentes são completamente ortogonais a objetos e não
oferecem o que é removido ao não lidar com objetos (i.e. lidar com
estado e comportamento como coisas separadas, Bo e VO). Camadas
oferecem agrupamento por responsabilidade e componente oferece
pedaços de software com contratos bem definidos.

Assim como elas não exigem o uso de OO não trazem os benefícios desta
por si só. Ainda que trouxessem, continua sendo extremamente
ineficiente utilizar uma linguagem OO sem fazer uso do paradigma.

Fernando Lozano:

No lado da modelagem conceitual, procure informações sobre a modelagem de negócios. Neste
campo se torna bem explícito que existem objetos que representam informação e objetos que
representam processos de negócios e fluxos de trabalho.

Além disso não fazer muito sentido para mim (exceto por mal uso de
arquétipos do RUP para objetos) os conceitos de modelagem de negícios
não falam sobre objetos da OO.

Exato e exatamente para não aumentar o acomplamento (além de diversas
outras vantagens) que objetos possuem estado e comportamento em si
mesmo.

Este trecho traz um problema clássico de modelagem: objetos -mesmo
em Domain Model, Domain Driven Design, o que for- não são a
representação do mundo real. Eles representam uma
abstração e pode ser possível que nesta abstração vendedores
não se tornem clientes.

Além disso, como exatamente não ter estado e comportamento no mesmo
lugar ajudaria?

Isso não faz muito sentido. Em uma determinada modelagem, para um
determinado cenário, isso pode ser verdade mas é apenas um de milhares
de modos de usar objetos.

Não sei qual o conceito de acoplamento do autor do email mas creio que
ele foge completamente do conceito difundido em engenharia de
software. Utilizando esta estratégia o acoplamento
aumenta:

1. Sempre que você precisar de uma operação vai ter que
   levar duas classes, os dados e a lógica, em vez de apenas uma, que é o
   objeto.
2. Sempre que a classe de dados alterar a classe de lógica vai ser
   alterada (além de acoplamento quebra encapsulamento)

Não entendo o que o “relacional” tem a ver com o tópico.

Este trecho mostra o mesmo problema em confundir mundo real com
abstração falado acima.

Este trecho mostra uma confusão entre conceitos bem interessante. Se
quisermos utilizar um objeto em múltiplos sistemas ele precisa ser de
uma Camada de Domínio (Page-Jones) baixa. No exemplo ele usa um objeto
da Camada de Aplicação (que, por definição, só é utilizada em uma
aplicação) e pega apenas seus dados para passar para outra
aplicação. Você não precisa de objetos burros para isso -e como
objetos burros quebram o encapsulamento estes vão dificultar ainda
mais- basta tornar Vendedor uma abstração numa Camada mais baixa.

Exemplo: Na aplicação de frente de caixa temos o objeto Vendedor. O
objeto Vendedor está associado a um objeto funcionário. O objeto
funcionário está numa Camada abaixo, de negócios, ele não possui
qualquer dependência com a aplicação de venda. A aplicação do RH
define sua própria classe, digamos que seja Beneficiário, que possui
uma associação com o Vendedor. Pronto, classe reutilizada e nenhum
objeto burro necessário.

Nota: Isso é só um exemplo. Se você quer saber porque este tipo
de coisa é tão difícil na prática leia sobre componentes
reutilizáveis.

Sabendo que instance-based components não fizeram sucesso esta
afirmação é duvidosa. Como 3 anos mudam muito as coisas espero que a
noção de reusabilidade deste trecho já tenha sido revista pelo autor.

Este trecho não faz o menor sentido. Existem papéis para objetos em
sistemas -padrões em Domain Driven Design ou Analysis Patterns são
exemplos destes- mas não há a separação não-proposital
(i.e. Transaction Script/Smart UI…) de dados e lógica, simplesmente
porque sem isso você não tem objetos.

Isso não faz sentido. Eu não sei exatamente em que ponto do exemplo
ele se apegou mas Camadas são ortogonais a objetos.

Não. Sem receber junto a lógica (i.e. recebendo uma estrutura
de dados ao invés de um objeto) eu preciso fazer com que minha Camada
de Apresentação (que cria e manipula o “objeto de dados” - sic) saiba
demais sobre meu objeto. Da mesma forma eu preciso que minha Camada de
Negócios saiba demais sobre o objeto. Resultado? Quando eu mudar algo
neste objeto eu preciso mudar também quem o cria e todos que o
utilizam. Isso é exatamente o oposto do encapsulamento.

Processos de negócios podem ser objetos. Se o processo é algo
significativo o suficiente (e não apenas um bando de interações) ele
pode facilmente ser representado de diversas formas -Domain-Driven
Design, Services, como exemplo- sem classes burras.

Ótima sugestão! Eu recomendo ao autor a releitura, especialmente na
seção 1.2 Information/Implementation Hiding e provavalmente todo o
capítulo 8. E, na verdade, o livro é bem abstrato, cheio de conceitos
e não traz muitas pistas para implementação das técnicas, mas esta é a
minha opinião.

Ops, mais uma confusão a vista. Como eu citei acima, Page-Jones fala
em Camadas de Domínio, que é algo diferente das nossas
arquitetura-de-N-camadas. Mas sim, ele é bastante útil.

Mais ou menos, mas de qualquer forma este trecho confirma a confusão
entre Camadas de Page Jones e Camadas como definidas pelo Fowler em
POEAA e pelo Buschman.

E eu imagino de que tipo de faculdade Fowler, Evans, Buschman,
Page-Jones, Yourdon e tantos outros tiraram aquelas técnicazinhas
teóricas…

–

O outro email é um repeteco deste, então vou ficar por aqui.

Pelo que eu entendi deveriamos ter os estados e comportamentos todos juntos em um objeto.

Ou seja seria errado simplesmente criar um POJO(objeto com seus atributos e métodos getters e setters).

esse objeto teria toda regra de negócio pertencente a ele.

E para trabalharmos , criariamos classes de serviço.(que tratem de regras especificas)

Bom de qualquer forma, a maneira como trabalho ou pelo menos é que mais vejo é: criar um objeto pojo só para representar a tabela do banco
e usar a model para validar as regras de negócio.

De fato se formos pensar na questão acoplamento , sim o pojo esta fortemente acoplado a classe de negócio

Se mudar o pojo mudarei também a classe de negociol.

Gostaria de saber se o certo então seria criar um classe pojo que valide suas próprias regras de negócio.

E se necessário criar um classe do tipo service que trata aquele objeto de forma específica.

wat