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.
[quote=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.[/quote]
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:
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.
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.