Olá, então como havia pensado mesmo usando OO + Design Patterns sem DDD seu Domain seria pobre e acabaria atuando como puppet(fantoche), sendo manipulado por outros objetos, o que caracteriza um modelo anêmico visto que o comportamento esta separado dos estados do objeto.
Obrigado pela resposta!
Fugindo um pouco do assunto, falando do padrão façade, de acordo com esta definição:
Fonte:
http://www.allapplabs.com/java_design_patterns/facade_pattern.htm
O padrão Façade esconde a complexidade atraves de uma interface, certo? Então quando eu tenho um setQualquer coisa, que realiza varias operacoes, para setar um valor, seria um tipo de Façade?
Ou seja a implementação esta escondida eu so disponibilizei a “interface”, se amanha eu quiser mudar o metodo isso nao afetaria meu cliente;
Isso seria uma Façade ou viajei d+.
Valeu
[quote=GOF sobre Façades]Intenção:
Fornecer uma interface unificada para um conjunto de interfaces em um subsistema. Façade define uma interface de nível mais alto que torna o subsistema mais fácil de ser usado.[/quote]
Basicamente ao invés dos teu sistema chamar várias classes de um subsistema, ele chama somente uma classe, e essa encarrega de distribuir os comandos para os responsáveis. É um encapsulamento como você mesmo diz, mas de mais alto nível.
Obrigado pela explicação deixa ver se eu entendi, digamos que tenha duas classes com varios metodos diferentes mas que tenha relação uma com outra, tipo PessoaFisica, e PessoaJuridica cada uma com seus metodos, seria uma Façade eu criar um interface por exemplo Pessoa, e de acordo com o parametro que receber eu invocar metodos em PessoaFisica ou em Juridica?
Valeu
O teu exemplo parece mais uma deficiência de uso de polimorfismo que uma Façade.
Façade é uma painel de controle unificado de várias máquinas complexas que fazem parte de um mesmo sistema/fábrica/etc específico.
É beeem alto nível.
Realmente o exemplo foi péssimo. Mas agora deu pra entender.
Att
[quote=danielbussade] Olá, voltando a idéia inicial do post sobre classes anêmicas, me surgiu outra dúvida, quando não se usa DDD ou seja o seu modelo não fala a mesma língua do cliente, e suas regras de negócio não estão no Domain, e sim espalhadas entre Controller, Façades, etc. As classes acabam se tornando anêmicas não?? Qual seria um alternativa OO em relação ao DDD, sem deixar as classes anêmicas??
[/quote]
É perfeitamente possível ter um software completamente baseado em ‘objetos de verdade’ sem correta divisão de camadas, sem domain-driven design e um péssimo design de alto nível. Você pode ter um bom micro-design e um péssimo macro-design.
Olá Philip, poderia me dar um exemplo. Não consigo visualizar um software totalmente OO sem domain driven design ou sem camadas.
Poderia explicar melhor micro-design e macro-design.
Valeu
[quote=danielbussade] Olá Philip, poderia me dar um exemplo. Não consigo visualizar um software totalmente OO sem domain driven design ou sem camadas.
Poderia explicar melhor micro-design e macro-design.
Valeu[/quote]
Seus OBJETOS se relacionam, possuem estado, comportamentos, etc.? Sim? Ok, você está usando orientação a objeto. A questão então é: seus objetos possuem um QI a mais voltado ao mundo real?
[quote=peerless]
Seus OBJETOS se relacionam, possuem estado, comportamentos, etc.? Sim? Ok, você está usando orientação a objeto. A questão então é: seus objetos possuem um QI a mais voltado ao mundo real? [/quote]
Exato.
Domain-Driven Design é sobre linguagem. Se você não usa no código a mesma linguagem que seus usuário você ainda pode ter objetos.
Exemplo:
Seu usuário diz: “Um carro estaciona em uma vaga”. Mas no seu código você tem:
class Estacionável{
List<Posicao> vagasPossiveis;
String id;
public void estacionar(String idDaPosicao){
for(Posicao p: vagasPossiveis){
if(p.getId().equals(idDaPosicao){
p.ocupadaPor(this);
}
}
}
}Contra uma alternativa Domain-Driven Design:
class Carro{
String placa;
public void estacionarEm(Vaga v){
v.ocupadaPor(this);
}
}Qual a diferença? Em um exemplo isolado pode parecer apenas nomenclatura mas é bem mais que isso, é o fato de que o segundo exemplo tenta implementar o domínio com suas relações, sem “inventar” nenhuma relação que não existe no mundo real (como a de Estacionavel com lista de posicoes no segundo exemplo).
Este texto pode ajudar: http://fragmental.tw/2008/09/23/object-oriented-design-which-how-and-what/
[quote=pcalcado]
Exato.
[…]
Este texto pode ajudar: http://fragmental.tw/2008/09/23/object-oriented-design-which-how-and-what/[/quote]
Ok, philip a questão então eu posso ter um software totalmente OO ou seja com meus objetos possuindo estado se relacionando, mas mesmo assim não ter DDD, porque meu modelo não fala a mesma “língua” do meu cliente ou do mundo real.
Isso eu entendi , agora o que me pergunto eh o seguinte se meu modelo não modela o mundo real, minhas classes acabam tendo um "que " de anemica visto que elas serao manipuladas por outras, o que deveria ser de responsabilidade delas.
Neste exemplo mesmo que você deu, estacionar eh uma responsabilidade do Carro , ou seja tendo uma vaga disponivel ele deve saber estacionar e não da classe Estacionável, o que faria do minha classe apenas um agrupamento de dados.
Então o que pergunto eh seguinte, sem DDD minhas classes não vão ter um “QI” alto sendo assim, irão acabar sendo anêmicas, então que alternativas teria e relação a DDD, para não deixar minhas classes tão “burras” assim?
Obrigado
Entendo o que você quer dizer mas acho que o problema é que você não está conseguindo distinguir o que é Orientação a Objetos e modelagem de domínio. Quem tem que estacionar é o carro… por quê? A única coisa que te diz isso é o domínio, não Orientação a Objetos. A classe do exemplo acima etá de acordo com o que se espera de um bom design OO (creio) mas não está de acordo com o domínio.
Ah táa acho que agora entendi. Então o simples fato de ter regras de negócio no Domain, não implica o uso do DDD ou seja minhas classes podem não ser anemicas, tendo varios metodos de negocio nela e mesmo assim eu nao usar DDD, ou seja eu posso usar um Domain Model Pattern sem usar DDD,mas nunca posso ter DDD sem ter um Domain Pattern certo?
Então eu poderia dizer que DDD está mais ligado a linguagem de negócios do que orientação a objetos em si??
Valeu
Isso.
Valeu philip pela ajuda!