Opa, segurem suas cartas!
[quote=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.[/quote]
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.
[quote=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. [/quote]
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.
[quote=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.[/quote]
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?
[quote=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?[/quote]
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.
[quote=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.[/quote]