Agora iremos postar alguns exercicios comentado durante as aulas.
Exercícios:
1º) Um objeto "A" precisa executar um método quando o estado do objeto "B" for alterada. Qual o padrão GOF deve ser usado? Qual o papel do objeto "B" e do objeto "A" nesse padrão?
Resposta
Padrão observer,
você deve pensar que um objeto, que chamarei de "A", irá executar uma ação que outros deverão capturar, que chamarei de "B".
2º) Qual o padrão GOF deve ser usado quando necessitamos executar diversas ações de forma atômica?
Resposta
Padrão Command.
Permite Encapsular uma solicitação como um objeto, permitindo desta forma parametrizar clientes com diferentes solicitações, enfileirar ou fazer o registro (log) de solicitações e suportar operações que podem ser desfeitas
3º) Uma classe de conexão só pode ter, no máximo, 10 instâncias. Qual o padrão GOF a usar?Resposta
Padrão Singleton
4º) Duas classes "A" e "B" tem iterfaces distintas. Qual o padrão deve ser usado se a classe "B" precisar um método da classe "A" ?
Resposta
Padrão Adapter, pois tem função que faz com que a interface de uma classe possa ser "adaptada" à interface de uma outra para que essas possam trabalhar juntas.
5º) Voçê deseja que uma classe de terceiros use um método de sua classe. Qual o melhor padrão?
Padrão Command.
Esta operação pode ser encapsulada em um objeto, assim reduziremos o acoplamento entre o as camadas.
quinta-feira, 22 de maio de 2008
quinta-feira, 15 de maio de 2008
Padrão MVC - Aula 25 e 26
Introdução.
Model View Controler (MVC)
O MVC é um padrão que serve para organizar as iterações entre os componentes da camada de apresentação. Esse padrão define três tipos de componentes:
• View são componentes que geram a parte da aplicação visível ao usuário do sistema. Pode ser uma pagina JSP, uma Janela Swing, um arquivo XML, entre outros. A View deve implementar o padrão Observer (FREEMAN et al, [199?]) em cima dos objetos do Model. Sempre que um objeto do Model mudar isso deve ser refletido nas Views que possam estar associadas ao referido objeto e conseqüentemente, nos dados que são mostrados ao usuário.
• Model são os componentes que contém as informações que vão ser mostradas na View. Pode ser o próprio objeto do modelo da aplicação (objeto da Camada de Modelo, Capítulo 4) ou apenas uma interface para os objetos do modelo.
• Controler são os componentes responsáveis por capturar solicitações vindas da View e as despacha para o Model. Além de atualizar a View apropriadamente. Para sistemas simples, onde a camada de aplicação não possui muitas funcionalidades, o Controler acaba as implementando.
É bom ressaltar, os três tipos de componentes acima pertencem a Camada de Apresentação e não são camadas separadas do sistema. Mas para aplicações simples, é aceitável Controler seja utilizando como substituto da Camada de Aplicação e Model como substituto da Camada de Modelo1.
O MVC com todas as suas funcionalidades não é possível de ser implementado em aplicações Web, visto que o protocolo HTTP não permite que o servidor, onde está o modelo, notifique o cliente onde está a View. O que realmente é implementado em aplicações Web é o padrão Front Controller (FOWLER,et al, 2002).
Normalmente não é preciso implementar esse padrão quando vai se desenvolver um sistema. Muitos Frameworks que trabalham com a Camada de Apresentação já o implementam, basta apenas utilizá-lo, como é o caso dos componentes Swing para aplicações desktop em Java.
Existem duas discussões sobre o padrão MVC: separar o Controler da View e separar a View do Model (FOWLER,et al, 2002). A primeira é menos importante e deve ser feita apenas quando a situação realmente exigir. A separação da View do Model é umas das mais importantes indicações de bom design de software. Entre as inúmeras vantagens pode-se citar:
• Desenvolvedores se especializam em apenas em das áreas, ou no design e técnicas de usabilidade de software ou construção de lógica de negócio, acesso a Banco de Dados, desempenho, entre outros. É difícil encontra um desenvolvedor que seja bom nas duas áreas (FOWLER,et al, 2002).
• Geralmente, softwares devem mostrar a mesma informação de maneiras diferente, dependendo do contexto que se tenha, locais e meios de acesso distintos, usuários com diferentes permissões, separar View do Model permite desenvolver múltiplas apresentações para o mesmo conteúdo.
• Objetos não visuais são mais fáceis de serem testados.
Agora em diante iremos abordar ao assunto de PADRÕES DA CAMADA DE APRESENTAÇÃO
Serão apresentados neste capítulo padrões para a camada de apresentação. A camada de Apresentação é a parte do sistema onde ficam os objetos responsáveis por fornecer algum serviço a uma entidade externa, seja essa entidade uma pessoa e a resposta em páginas.
Serão apresentados neste capítulo padrões para a camada de apresentação. A camada de Apresentação é a parte do sistema onde ficam os objetos responsáveis por fornecer algum serviço a uma entidade externa, seja essa entidade uma pessoa e a resposta em páginas.
Padrão MVC
Model View Controler (MVC)
O MVC é um padrão que serve para organizar as iterações entre os componentes da camada de apresentação. Esse padrão define três tipos de componentes:
• View são componentes que geram a parte da aplicação visível ao usuário do sistema. Pode ser uma pagina JSP, uma Janela Swing, um arquivo XML, entre outros. A View deve implementar o padrão Observer (FREEMAN et al, [199?]) em cima dos objetos do Model. Sempre que um objeto do Model mudar isso deve ser refletido nas Views que possam estar associadas ao referido objeto e conseqüentemente, nos dados que são mostrados ao usuário.
• Model são os componentes que contém as informações que vão ser mostradas na View. Pode ser o próprio objeto do modelo da aplicação (objeto da Camada de Modelo, Capítulo 4) ou apenas uma interface para os objetos do modelo.
• Controler são os componentes responsáveis por capturar solicitações vindas da View e as despacha para o Model. Além de atualizar a View apropriadamente. Para sistemas simples, onde a camada de aplicação não possui muitas funcionalidades, o Controler acaba as implementando.
É bom ressaltar, os três tipos de componentes acima pertencem a Camada de Apresentação e não são camadas separadas do sistema. Mas para aplicações simples, é aceitável Controler seja utilizando como substituto da Camada de Aplicação e Model como substituto da Camada de Modelo1.
O MVC com todas as suas funcionalidades não é possível de ser implementado em aplicações Web, visto que o protocolo HTTP não permite que o servidor, onde está o modelo, notifique o cliente onde está a View. O que realmente é implementado em aplicações Web é o padrão Front Controller (FOWLER,et al, 2002).
Normalmente não é preciso implementar esse padrão quando vai se desenvolver um sistema. Muitos Frameworks que trabalham com a Camada de Apresentação já o implementam, basta apenas utilizá-lo, como é o caso dos componentes Swing para aplicações desktop em Java.
Existem duas discussões sobre o padrão MVC: separar o Controler da View e separar a View do Model (FOWLER,et al, 2002). A primeira é menos importante e deve ser feita apenas quando a situação realmente exigir. A separação da View do Model é umas das mais importantes indicações de bom design de software. Entre as inúmeras vantagens pode-se citar:
• Desenvolvedores se especializam em apenas em das áreas, ou no design e técnicas de usabilidade de software ou construção de lógica de negócio, acesso a Banco de Dados, desempenho, entre outros. É difícil encontra um desenvolvedor que seja bom nas duas áreas (FOWLER,et al, 2002).
• Geralmente, softwares devem mostrar a mesma informação de maneiras diferente, dependendo do contexto que se tenha, locais e meios de acesso distintos, usuários com diferentes permissões, separar View do Model permite desenvolver múltiplas apresentações para o mesmo conteúdo.
• Objetos não visuais são mais fáceis de serem testados.
O ponto chave para essa separação é que a View pode depender do Model, mas o Model deve ser independente da View. O esquema de dependência do padrão MVC é mostrado na Figura abaixo:
Esquema de dependências do padrão MVC
quarta-feira, 7 de maio de 2008
Padrão COMMAND - Aula 23 e 24
Padrão COMMAND
A principal função do padrão Command é encapsular invocações a objetos. Quando invocar objetos torna-se uma tarefa complexa, como é o caso de invocar componentes remotos na especificação EJB 2.1, há a necessidade de se encapsular essas invocações para se simplificar o código. Com isso são abstraídas, para o cliente, coisas do tipo: onde, quando ou qual componente vai realizar uma determinada tarefa.
O principio do padrão é guardar um “objeto comando” para cada objeto a ser invocado. Para invocar o objeto destino, invoca-se sempre o mesmo método do “objeto comando” (geralmente chamado de execute) e esse método padrão de um comando se encarrega de chamar os métodos adequados para realizar as ações requeridas. Com isso evita-se que o código do cliente fique poluído com várias estruturas de seleção (“Ifs”) testando o tipo do objeto a ser invocado para chamar o método apropriado.
O Command gera uma maior flexibilidade na arquitetura do sistema, uma vez que permite a adição de novas funcionalidades (comandos) sem a necessidade de mudar o design da arquitetura. Outro ponto positivo do padrão Command é que ele posibilita desfazer as ações realizadas por um comando. Para isso, é necessário implementar um método no comando (geralmente chamado de undo) que realize as operações contrárias as operações realizadas quando o comando foi invocado.
Um ponto negativo para esse padrão é que ele deixa o design da aplicação
“procedural”, isto é, orientado a ações.
Exemplo de Uso do padrão Command
No exemplo dessa subseção, será mostrada a implementação do padrão Command, para se modelar a ação de se ligar um aparelho de Televisão.
/** todo comando implementa a mesma interface
* que consiste de apenas um metodo */
public interface Command {
public void execute();
public void undo();
}
A principal função do padrão Command é encapsular invocações a objetos. Quando invocar objetos torna-se uma tarefa complexa, como é o caso de invocar componentes remotos na especificação EJB 2.1, há a necessidade de se encapsular essas invocações para se simplificar o código. Com isso são abstraídas, para o cliente, coisas do tipo: onde, quando ou qual componente vai realizar uma determinada tarefa.
O principio do padrão é guardar um “objeto comando” para cada objeto a ser invocado. Para invocar o objeto destino, invoca-se sempre o mesmo método do “objeto comando” (geralmente chamado de execute) e esse método padrão de um comando se encarrega de chamar os métodos adequados para realizar as ações requeridas. Com isso evita-se que o código do cliente fique poluído com várias estruturas de seleção (“Ifs”) testando o tipo do objeto a ser invocado para chamar o método apropriado.
O Command gera uma maior flexibilidade na arquitetura do sistema, uma vez que permite a adição de novas funcionalidades (comandos) sem a necessidade de mudar o design da arquitetura. Outro ponto positivo do padrão Command é que ele posibilita desfazer as ações realizadas por um comando. Para isso, é necessário implementar um método no comando (geralmente chamado de undo) que realize as operações contrárias as operações realizadas quando o comando foi invocado.
Um ponto negativo para esse padrão é que ele deixa o design da aplicação
“procedural”, isto é, orientado a ações.
Exemplo de Uso do padrão Command
No exemplo dessa subseção, será mostrada a implementação do padrão Command, para se modelar a ação de se ligar um aparelho de Televisão.
Para se implementar o padrão Command, primeiro é necessário criar uma interface que contenha os métodos comuns para um comando. Esses métodos são o execute, para executar a ação do comando e se for necessário, o método undo para desfazer a ação realizada. O código dessa interface pode ser visto abaixo:
/** todo comando implementa a mesma interface
* que consiste de apenas um metodo */
public interface Command {
public void execute();
public void undo();
}
Assinar:
Postagens (Atom)
