pcalcado wrote: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?

FL wrote:
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.

Fernando Lozano wrote:
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. Conceituamente, é
muito boa a idéia de um objeto auto-contido, mas na prática as interações entre os objetos e os
vários detalhes relativos a tecnologia (web, gui, persistência, transações, segurança, auditoria, etc),
que não entram em um modelo de objetos de domínio, acabam se imponto

Fernando Lozano wrote:
Hoje as técnicas de
programação em camadas e baseadas em componentes trazem muitas idéias e práticas úteis para o
desenvolvedor OO. Note bem, desenvolvimento em camadas e desenvolvimento com
componentes não exigem o uso de OO, ao contrário do que muitos pensam, e evoluíram de forma
relativamente independente das técnicas OO.

Fernando Lozano wrote:
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.

Fernando Lozano wrote:
Não que um objeto de dados tenha que
ser reduzido ao BDO dos J2EE Blueprints (e note que um VO é mais do que um BDO, apesar
destes termos serem usados como sinônimos na maioria das vezes), mas ele tem que conter a
funcionalidade que se aplica a ele mesmo, apenas. Ir além disso aumenta o acoplamento e acaba
por dificultar a manutenção a longo praso das aplicações.

Fernando Lozano wrote:
Um erro comum é confundir o processo com a pessoa ou cargo que o desempenha. No mundo real
todas as pessoas e todos os cargos participam de partes diferentes de vários processos, então
qualquer modelo que se limite a coisas como cliente, vendedor e produto estará falho em sua
representação do mundo real. Entretanto é muito mais fácil identificar e modelar estes objetos
"concretos", sobre os quais são armazenadas muitas informações, do que identificar e modelar
processos mais abstratos como um "processo de venda a crédito" ou "processo de venda por
telefone".

Fernando Lozano wrote:
Um objeto de negócios, significando um objeto que representa um processo ou fluxo de trabalho,
não representa informação persistente (embora possa ser necessário salvar informações transitórias
sobre o estado do processo no banco de dados), mas sim uma atividade em andamento. Esta
atividade utiliza vários objetos de dados, delegando para eles o que eles sabem fazer sozinhos, mas
coordenando a interação deles com outos objetos.

Fernando Lozano wrote:
Isto reduz bastante o acoplamento entre os
objetos, pois os mesmos objetos de dados podem ser reutilizados por vários objetos de negócios.
Mas se os próprios objetos de dados fazem chamadas a outros objetos de dados, o conjunto todo
fica indivisível, dificultando a reutilização. Por outro lado, mudanças nos processos de negócios
podem ser acomodadas de forma mais pontual, modificando-se o objeto que representa este
processo, e não vários objetos de dados que participam deste processo (a não ser que o novo
processo exija informações diferentes).

Fernando Lozano wrote:
Já os objetos de dados tem que ser conceituais, complexos. É uma falha muito comum pensar neles
de forma "relacional", quebrando por exemplo uma nota fiscal e seus itens. Pensa-se em objetos
simples, com atributos numéricos ou textuais, quando estes atributos poderiam (e em geral
deveriam) ser outros objetos complexos e coleções de objetos.

Fernando Lozano wrote:
Olhando para o seu exemplo, por que cliente.comprar tem que chamar vendedor.vende, criando
acoplamento artificial entre as duas classes? Agora, se o cliente compra com cartão de crédito,
quem valida o cartão, é o vendedor ou o cliente? Ou vai criar um objeto "caixa", que fica amarrado
a cliente e a vendedor? Para que o produto seja entregue ao cliente, ele tem que ser retirado do
estoque, qual objeto (vendedor, cliente ou caixa) faz isso? Cria-se também o objeto "amoxarife"?
Observe como o que parece superficialmente cirar um vínculo aceitável, intuitivo entre dois
objetos, acaba mascarando vários vínculos que não são intuitivos e criando várias dependências
não-obvias, que irão dificultar a manutenção. O desenvolvedor que modifica o módulo de cartões
de crédito (ou cheque pré-datado) não espera que ele possa gerar efeitos colaterais no cliente ou no
vendedor. Mas um objeto de negócios controlando o procesos de vendas torna essas dependências
explícitas, então o desenvolvedor sabe que modificar o objeto de cartão de crédito pode afetar o
processo de venda. Ao mesmo tempo, isola os objetos cliente e vendedor
desta mudança.

Fernando Lozano wrote:
Seguindo adiante, o objeto vendedor será utilizado não apenas na aplicação de frente de loja, que
cuida das vendas. Será utilizado na aplicação de folha de pagamento, que toda no back-end
administrativo e financeiro. Aí o objeto vendedor precisa fornecer informações sobre o seu
percentual de comissões e seu salário fixo, informações que não interessam à frente de loja. O que é
menos pior, onerar o sistema de frente de loja com informações e funcionalidade que só interessam
ao departamento de pessoal, ou onerar o sistema de pessoal com informações que interessam
apenas à frente de loja (e talvez ao contas a pagar e receber) como cartão de crédito? Ou então
esquece-se OO e cada sistema tem sua definição única e incompatível de cada objeto?

Fernando Lozano wrote:
Em suma, a visão OO clássica, como se aprende na faculdade, pode funcionar bem quando se
pensa em aplicações isoladas, mas não se mantém tão bem quando se pensa em várias aplicações
dentro de uma mesma organização, e na necessidade de compartilhar informações e código entre
essas aplicações para ganhar produtividade no desenvolvimento das próprias aplicações e
consistência e gerenciabilidade sobre as informações. Por isso há a necessidade de evoluir a visão
OO reconhecendo que nem todos os objetos são iguais entre si e devem ser tratados da mesma
forma. Não que a visão clássica esteja "errada", mas ela é limitada em sua aplicabilidade.

Fernando Lozano wrote:
A classificação dos objetos em objetos de dados e objetos de atividade (processo ou fluxo) é uma
divisão conceitualmente coerente com as práticas OO, porque reconhece o papel de cada objeto
dentro de um sistema maior. O design baseado em responsabilidades é uma prática bem aceita e
antiga no desenvolvimento OO.

Fernando Lozano wrote:
Este estilo de desnevolvimento é mais fácil de aplicar junto com o desenvolvimento em camadas.
Você mesmo viu a necessidade de seaprar em um mesmo objeto conceitual a funcionalidade
exigida por sistemas diferentes, ou a funcionalidade exigida por camadas diferentes como
persistência e apresentação. E para concilia-la com a idéia dos objetos de dados incorporando toda
a funcionalidade de negócios neles mesmo comecou a criar artifícios como subclasses e interfaces
artificiais, dificultando o entendimento de um sistema e consequentemente sua manutenção.
Chamar de "apectos" piora ainda mais a coisa, pois induz ao uso de programação orientada a
aspectos, que não tem nada a ver com isso. Usar a herança para separar partes do objeto não ajuda
nada, pois a herança sempre soma mais, acopla mais, em vez de separar e isolar.

Fernando Lozano wrote:
Veja bem, não é melhor ter um objeto de apresentação que recebe um objeto de dados cliente, sem
trazer junto a lógica para compras, cartão de crédito e estoque? Isto não facilitaria no futuro expor
parte do processo como um web service para interfaces com o usuário diferentes, ou separar a
aplicação em um "cliente rico" que roda na máquina do usuário, mas acessa objetos de negócio em
um servidor EJB ou por RMI? Não é mais fácil ter um objeto que se preocupa com a persistência
dos dados de compras de um cliente sem se preocupar se este cliente também pode ter dados de
reclamações ou de consertos pendentes?

Fernando Lozano wrote:
Não seria melhor explicitar no seu modelo a existência de processos de negócios, em vez de deixa-
los embutidos e "escondidos" dentro das classes de dados? Não seria melhor explicitar no seu
modelo quando uma mesma "pessoa" pode desempenhar vários papeis diferentes (por exemplo o
cliente que compra um produto e o cliente que faz uma reclamação ou aciona a assistência técnica,
ou ainda o cliente que recebe um produto entregue por correio do cliente que paga pelo produto)?

Fernando Lozano wrote:
Sugiro para você e seus colegas a leitura do livro "Projeto Orientado a Objetos" de Meilir Page-
Jones. Ele é cheio de dicas concretas sobre como construir modelos de classes, quando suar herança
e quanto usar agregação, explorando erros comuns como os do seu exemplo. É um livro diferente
dos outros do mercado porque ele, em vez de discutir modelagem de objetos de forma abstrata,
sem nunca criar implementações reais dos sistemas modelados, discute de forma concreta,
apresentando todos os percalços que ocorrem quando o modelo é traduzido para uma aplicação
real. Melhor ainda, ele usa Java para os exemplos de código.

Fernando Lozano wrote:
Neste livro também é explicado um modelo de camadas genérico, ao qual toda linguagem de
programação, framework, biblitoteca ou aplicação se enquadra. Este modelo parte da aplicação, no
nível mais alto, para o hardware, no nível mais baixo. é muito útil colocar seus objetos dentro deste
modelo, e assim isolar objetos cuja única função é lidar com uma tecnologia específica (como um
DAO para bancos relacionais, ou um cliente para um web service, ou um action do struts) com
objetos cuja função é lidar com uma parte do negócio.

Fernando Lozano wrote:
Tanto objetos focados em tecnologia quanto objetos focados em negócio são reutilizáveis, mas de
formas diferentes. Os primeiros em aplicações totalmente não relacionadas, mas que usem a
mesma tecnologia; os segundos em aplicações da mesma área de negócios ou da mesma
organização, mesmo que usando tecnologias diferentes.

Fernando Lozano wrote:
Minhas sugestões são focadas em sistemas grandes, complexos, integrados, com muitos requisitos
de performance e segurança, coisa que não aparecem em um artigo de revista ou exemplo didático
na faculdade. Coisas que também são frequentemente relegadas nas empresas, que desenvolvem
sistemas de forma muito imediatista, privilegiando objetivos de curto praso e esquecendo que a
maior parte do custo de um sistema são na manutenção, que inclui não apenas mudanças no
negócio em si, como concorrência e leis, mas também na tecnologia, como criar uma interface web
onde não havia, ou criar um web service para acesso externo a um sistema que originalmente era
apenas de uso interno.