Suponha que eu tenha uma aplicação do tipo cliente/servidor.
Eu tenho uma classe X que contém métodos que fazem acesso diretamente a base.
E tenho uma classe Y que é a classe através da qual todas as outras classes fazem acesso a base, ou seja, fazem acesso a classe X.
Então eu posso dizer que a classe Y é um façade?
Thanks in advance!!
acho que sim…
Creio que não, mais não sei…
Acho que isso esta mais p/ DAO já que voce encapsula o acesso aos dados em uma classe e usa sua interface em outra.
O objetivo de um Facade é criar uma interface simples (de mail alto nível) p/ manipulação de um subsistema geralmente delegando as classes desse subsistema. E dessa maneira você também ganha um pouco mais de flexibilidade já que caso precise alterar o comportamento do sistema basta mexer no Facade.
Acho que o conceito de DAO e o padrão façade não são excludentes. Todo DAO é também um façade, já que encapsula classes de um subsistema, as classes que efetivamente fazem a persistência, fornecendo uma interface mais simples, mais orientada aos objetos de negócio. Inclusive. no livro Design Patterns o terceiro exemplo do uso de façade é: “Quando você quer estruturar em camadas o seus subsistemas”, que é exatamente o caso do DAO.
No seu caso, se a classe Y simplifica o uso da classe X, creio que seja façade sim. O design pattern não define um tamanho mínimo para o subsistema e ainda ressalta que “os subsistemas podem tornam-se mais complexos a medida que evoluem”. Ou seja, com o tempo, a tendência é que a classe Y cresça em comparação com seu interior (que hoje tem a classe X, mas amanhã certamente terá a X, Z, K, W…).
Valeu pelas respostas!!!
Acho que a classe X é um DAO e a classe Y é um Facade.
Alguem tem algum link que fale de façade? pra eu dar uma pesquisada pois é um conceito novo pra mim
Eu diria possivelmente, mas o fato é que o cenário não está claro. Qual a função da classe Y ao servir como ponte para a X? Limitar o acesso? Adaptar sua interface? Simplificar a interface? Outro motivo? Existem muitos patterns semelhantes, o que distingue geralmente é o motivo dele.
Sim, na minha opinião Y é uma façade.
[quote=Omeganosferatu]Alguem tem algum link que fale de façade? pra eu dar uma pesquisada pois é um conceito novo pra mim
[/quote]
Cara, fiquei com uma curiosidade da porra: “Se eu te disser que sim, o que acontece? E se eu te disser que não?”
Não estou ironizando, é curiosidade mesmo.
Olá. Aproveitando o assunto sobre o pattern FACADE, gostaria de saber se os objetos FACADE (ou uma classe FACADE) é onde encontra-se as regras de negócios? 
[]'s
O façade ajuda você a separar subsistemas. Mas ele não especifica o tipo de subsistema.
Logo, você pode ter tanto um façade para os seus objetos de negócio, quanto um façade para seu módulo de persistência, quanto um façade para classes da view.
[quote=carlosmcp]Olá. Aproveitando o assunto sobre o pattern FACADE, gostaria de saber se os objetos FACADE (ou uma classe FACADE) é onde encontra-se as regras de negócios?
[]'s[/quote]
Pode conter também regras de negócio.
Por exemplo.
Diria que tens um sistema que tem uma classe ClienteNegocio(não é um bom nome, mas só para entender) para encapsular as regras de negócio sobre o cadastro de novos clientes.
Porém essa classe por sí só faz garantia de seu estado e em seu construtor recebe um objeto Session(uma sessão sei lá do que do seu sistema).
Para que um subsistema também fizesse inclusão de Clientes, este subsistema teria que implementar essa regra por obrigatoriedade também.
O que fazemos?
Um facade resolve isso.
Um facade abstrai o problema da Session e apenas recebe o cliente por parâmetro e faz o complemento para manipulação do objeto ClienteNegocio.
Mas e a regra de negócio?
Digamos que a cada inclusão de cliente, fosse automaticamente enviado um e-mail a este cliente, e esta regra estivesse stagnada em componentes externos ao ClienteNegocio?
O facade também abstrairia isso, e o subsistema apenas teria conhecimento sobre a criação deste cliente.
Não sei se fui bem claro, mas…
[quote]
Pode conter também regras de negócio.
Por exemplo.
Diria que tens um sistema que tem uma classe ClienteNegocio(não é um bom nome, mas só para entender) para encapsular as regras de negócio sobre o cadastro de novos clientes.
Porém essa classe por sí só faz garantia de seu estado e em seu construtor recebe um objeto Session(uma sessão sei lá do que do seu sistema).
Para que um subsistema também fizesse inclusão de Clientes, este subsistema teria que implementar essa regra por obrigatoriedade também.
O que fazemos?
Um facade resolve isso.
Um facade abstrai o problema da Session e apenas recebe o cliente por parâmetro e faz o complemento para manipulação do objeto ClienteNegocio.
Mas e a regra de negócio?
Digamos que a cada inclusão de cliente, fosse automaticamente enviado um e-mail a este cliente, e esta regra estivesse stagnada em componentes externos ao ClienteNegocio?
O facade também abstrairia isso, e o subsistema apenas teria conhecimento sobre a criação deste cliente.
Não sei se fui bem claro, mas…[/quote]
Fostes sim. É exatamente o pensamento que havia em mente! :D. Muito Obrigado a ti e a todos que escreveram também, pois só assim ‘conseguimos’ entrar em um consenso. Mas atenção, quem estiver lendo e tiver outra opinião, por favor, poste a sua visão (eu disse visão e não view 8) 
rs).
[quote=carlosmcp]Olá. Aproveitando o assunto sobre o pattern FACADE, gostaria de saber se os objetos FACADE (ou uma classe FACADE) é onde encontra-se as regras de negócios?
[]'s[/quote]
Cara, os Facades são apenas “fachadas” com a finalidade de encapsular ainda mais sua aplicação. Eles não devem conter as regras de negócios.
Imagine que vc tenha um pacote em sua aplicação que concentram todas as classes de regras de negócios e as classes deste pacote não podem ser acessadas diretamente pela view (por exemplo)…
…aí, para proteger a aplicação crio classes protected ou então sem modificador. Aí vc cria uma única classe no pacote que pode ser acessada por outras classes de fora do pacote. Todas as classes do pacote poderão ser acessadas apenas através desta classe. E a sua view irá acessar apenas o Facade.
Este é um exemplo mas existem outros casos de aplicação de facades.
Poder colocar regras de negócios em um facade até pode mas não é aconselhável, pelo menos não em minha opinião.
[]s
Vou buscar referências exatas sobre isso, mas até o que entendia.
Facade é exatamente para abstrair regras de negócio a subsistemas que vão acessar certa funcionalidade.
Então, sempre encarei o Facade como uma “ponte de ligação”, de acesso apenas. Mesmo assim, vou procurar me informar melhor também.
Já vi muitos programadores incluindo regras de negócios no Facades. Eu só não acho aconselhável pois se um dia precisar mudar a forma de acesso a banco ou mesmo a forma como enviar e-mails aos usuários, o Facade será mais um arquivo a ser alterado e na verdade não precisaria se ele não concetrar regras de negócio.
[]s
https://blueprints.dev.java.net/bpcatalog/ee5/persistence/facade.html
https://blueprints.dev.java.net/bpcatalog/ee5/persistence/namedquery.html
:lol: