Mas o que eu entendi é que se eu uso a abordagem de SOA, eu teria uma classe CD e uma classe CDPlayer, especializada no serviço de tocar CDs.
No caso do DomainModel (OOP), minha classe CD já não deveria ser responsável por tocar também?
Mesmo considerando que SOA é arquitetura e OOP design, se a resposta para a pergunta acima for afirmativa, me leva a concluir que essa arquitetura é incompatível com o design.
Não existe uma regra fixa. o Domain Model como descrito pelo Fowler (que é a bibliografia mais conhecida, creio) diz:
Criar Domain Models não é o único jeito de lidar com objetos, de qualquer forma, mas é o mais usual (teoricamente, na prática é bem diferente…)
Você pdoeria ter sim, no seu domínio, uma classe CdPlayer, se ela tivesse representação na sua lógica. O objetivo é modelar os participantes o mais próximo conveniente da realidade. Ninguém nunca pode te dizer que o seu CD deve se tocar sozinho ou deve precisar de um CdPlayer, a escolha é de quem projeta, não existe certo e errado, mesmo porque depende do contexto. O que se pdoe avaliar é que um CD tocando sozinho pode implicar em dependência X, acoplamento Y… e de repente você consegue um efeito melhor delegando a responsabilidade à outra classe. Tudo é subjetivo.
Esse trecho:
Mostra que o tal Dr. Hao ou não entendeu muito bem o que é OOD ou descobriu a verdade absoluta que todos devem seguir…
Nem a resposta é totalmente afirmativa ou negativa, nem os paradigmas são incompatíveis.
A primeira coisa a lembrar é que conceitos variam de acordo com autores ou escolas de pensamento.
Um objeto é um componente de baixo nível, mas ele oferece serviços. Empacote os objetos e você pode ter um componente de alto nível. Faça este componente implementar uma interface publicada e você tem um serviço oferecido por um componente, que pdoe ser substituído por qualquer outro desde que sia o contrato da Interface.
SOA é focada em serviços, Objetos também, o que os objetos oferecem são serviços rpestados através de suas relações com outros objetos, serviços estes expostos em sua API
O que me fica dificil entrar na cabeca é que no Domain Model os dados e as operações ficam juntas.
Posso ter o seguinte
ex:
class Funcionario
{
public Funcionario[] consultarFuncionariosEmDestaque()
{
}
}
Funcionario f = new Funcionario();
Funcionario[] fs = f.consultarFuncionariosEmDestaque()
eu preciso de uma instancia para consultar um conjunto de instancias.
Fica dificil entender isso.
Sou como o Mister M. Minha identidade é secreta, pois meu chefe não pode ver que fico o dia inteiro no forum (rsrsrsrsr).
Mas a classe Filial precisaria ter acesso ao repositório (DAO) de funcionarios.
Não seria interessante que só a classe de funcionario soubesse como buscar funcionarios ?
Dois "misters m"s ?Trabalha na Summa tb? :mrgreen:
Seria? por que? Por que não seria? Depende do caso, sempre (e é esse meu ponto contra o que escreveu o Dr. Who).
Note que persistir é uma limitação do ambiente (pouca memória, blablabla), não do seu modelo. Existem centenas (milhares?) de implementações possíveis ( AOP, proxies, DAOs, acesso direto…) que resolveriam esse problema, todas têm vantagens e desvantagens.
Mas isso seria uma das “vantagens” do SOA ?
O serviço ficaria responsavel por também persistir.
Há a desvantagem do serviço ter que conhecer dados que geralmente não precisariam ser conhecidos.
ex:
class Estoque
{
public void estocar(Material material)
{
// posso persistir, pois a acao de estocar implicitamente persiste um material.
// para validar tenho que conhecer alguns atributos
if (material.getDescricao() == "") //
MaterialDAO.salvar(material);
// ou MaterialRespositorio.salvar(material);
}
}
ou
class Material
{
public void estocar()
{
// acesso metodos internos, não preciso expo-los;
MaterialDAO.salvar(this);
}
}
Alias, convenhamos, esse exemplo do CD foi bem fajuto hein? Se tao tentando vender SOA, precisam arrumar um exemplo melhorzinho. Pq, como o shoes mencionou, eh perfeitamente valido ter cdPlayer.play(cd) em OO.
O que eu vejo de interessante na SOA, no entanto, eh bolar uma maneira inteligente pra integrar diversos sistemas diferentes colocando o foco nos servicos, e nao nos dados ou protocolos.
Baratinho, prático (demais até… :roll: ) e bem simples, mostra o que é desenvolver pensando em interfaces. Não esperem mais que uma breve introdução, entretanto. Aqui no rio tem na Ciência e Cultura (7 de Setembro, no Centro, na Tijuca também, provavelmente),e tem um curso de extensão na PUC-RIO baseado nele (Projeto de Software Orientado a Componentes com UM, com professor Rodrigues, no Centro, muito bom!).
Mas depois do momento Polishop, por que eu falei isso?
Porque numa arquitetura SOA você vai enxergar o mundo além das fronteiras do seu (sub)sistema como um bando de vendedores. Você quer comrpar uma laranja. Existem 15 vendedores de laranja. Qual o contrato básico?
Eu te dou uma quantidade de dinheiro, você me dá uma laranja que esteja em condições de consumo.
Como o cara guarda a laranja dele? Não me improta pelo cotnrato básico. Se eu quiser um diferencial para escolher o melhor vendedor, eu posso até pergutnar para eles (se quiserem/puderem falar), mas basicamente eu dou o dinheiro e pego a laranja, não importa de quem. Se o vendedor A falir, eu posso comrpar do B cumprindo o mesmo contrato, pagando com dinheiro e recebendo laranjas.
As vantagens do SOA não tem a ver coma implementação,porque SOA não diz sobre implementação. Ele diz que componentes fornecem serviços segundo contratos.
O livro do Cheesman ensina você a pensar em Interfaces (em demasia, até).
Mas a programação baseada em contratos é uma enorme vantagem.
ex:
estocar(material) para quem chama este método sempre vai desejar estocar um material, não importa como.
Para mim isto é uma enorme vantagem, pois qualquer funcionalidade extra no processo de estocar pode ser implementado sem problemas.
Opa, opa, há controvérsias. Primeiro que pelo menos 80% das informações da minha profissional estão na minha assinatura (ou linkadas a partir dela :-P) e depois que eu só leio o GUJ entre os builds da aplicação (que são muitos :-P).