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();
}
quarta-feira, 30 de abril de 2008
Padrão OBSERVER - Aula 21 e 22
Padrão OBSERVER
Como garantir que objetos que dependem de outro. Objeto fiquem em dia com mudanças naquele objeto?
– Como fazer com que os observadores tomem conhecimento do objeto de interesse?
– Como fazer com que o objeto de interesse atualize os observadores quando seu estado mudar?
• Possíveis riscos
– Relacionamento (bidirecional) implica alto acoplamento.
– Como podemos eliminar o relacionamento bidirecional?
O assunto a ser tratado hoje, será o Padrão Observer, segundo GOF "Definir uma dependência um-para-muitos entre objetos para que quando um objeto mudar de estado, todos os seus dependentes sejam notificados e atualizados automaticamente."
Ele é indicado para tratar situações de dependência. Sua utilização oferece o benefício de se relacionar duas ou mais classes sem criar um vínculo explícito entre elas.
O padrão Observer abstrai a relação dos objetos definindo-os como Observer e Subject.
Observer são objetos que ficam aguardando por uma mudança no estado de determinado objetos para poderem tomar uma ação. Subject são os objetos que estão sendo observados.
Olhando para nossa situação, o objeto Venda é um Subject e a notificação ao usuário e envio de arquivo são os Observers.
Observer são objetos que ficam aguardando por uma mudança no estado de determinado objetos para poderem tomar uma ação. Subject são os objetos que estão sendo observados.
Olhando para nossa situação, o objeto Venda é um Subject e a notificação ao usuário e envio de arquivo são os Observers.
Como garantir que objetos que dependem de outro. Objeto fiquem em dia com mudanças naquele objeto?
– Como fazer com que os observadores tomem conhecimento do objeto de interesse?
– Como fazer com que o objeto de interesse atualize os observadores quando seu estado mudar?
• Possíveis riscos
– Relacionamento (bidirecional) implica alto acoplamento.
– Como podemos eliminar o relacionamento bidirecional?
quarta-feira, 23 de abril de 2008
Padrão Singleton - Aula 20
Padrão singleton
Como vimos durante a aula esplanada pelo Professor João Bosco de Barro, a respeito do padrão Singleton que segundo GOF, "Garante que uma classe só tenha uma única instância, e prover um ponto de acesso global a ela."
O padrão Singleton apresenta vários benefícios:
Acesso controlado à instância única: Como a classe Singleton encapsula a sua única instância, possui controle total sobre como e quando os clientes a acessam.
Espaço de nomes reduzido: O padrão Singleton representa uma melhoria em relação ao uso de variáveis globais. Ele evita a poluição do espaço de nomes com variáveis globais que armazenam instâncias únicas.
Permite um refinamento de operações e da representação: A classe Singleton pode ter subclasses e é fácil configurar uma aplicação com uma instância dessa classe estendida. Você pode configurar a aplicação com uma instância da classe de que necessita em tempo de execução.
Permite um número variável de instâncias: O padrão torna fácil mudar de idéia, permitindo mais de uma instância da classe Singleton. Além disso, você pode usar a mesma abordagem para controlar o número de instâncias que a aplicação utiliza. Somente a operação que permite acesso à instância de Singleton necessita ser mudada.
Mais flexível do que operações de classe: Uma outra maneira de empacotar a funcionalidade de um singleton é usando operações de classe. Porém, tal técnica torna difícil mudar um projeto para permitir mais que uma instância de uma classe.
Como vimos durante a aula esplanada pelo Professor João Bosco de Barro, a respeito do padrão Singleton que segundo GOF, "Garante que uma classe só tenha uma única instância, e prover um ponto de acesso global a ela."
É necessário para algumas classes conter uma, e apenas uma, instância. Por exemplo, embora possam existir muitas impressoras em um sistema, deveria haver somente um spooler de impressoras. Da mesma forma, deveria haver somente um sistema de arquivos e um gerenciador de janelas. Um filtro digital terá somente um conversor A/D. Um sistema de contabilidade será dedicado a servir somente a uma companhia.
Como garantimos que uma classe tenha somente uma instância e que essa instância seja facilmente acessível? Uma variável global torna um objeto acessível, mas não impede você de instanciar múltiplos objetos.
Uma solução melhor seria tornar a própria classe responsável por manter o controle de sua única instância. A classe pode garantir que nenhuma outra instância seja criada (pela interceptação das solicitações para criação de novos objetos), bem como pode fornecer um meio para acessar sua única instância. Este é o padrão Singleton.
Como garantimos que uma classe tenha somente uma instância e que essa instância seja facilmente acessível? Uma variável global torna um objeto acessível, mas não impede você de instanciar múltiplos objetos.
Uma solução melhor seria tornar a própria classe responsável por manter o controle de sua única instância. A classe pode garantir que nenhuma outra instância seja criada (pela interceptação das solicitações para criação de novos objetos), bem como pode fornecer um meio para acessar sua única instância. Este é o padrão Singleton.
Quando usar Singleton?
Use o padrão Singleton quando:
For preciso haver apenas uma instância de uma classe, e essa instância tiver que dar acesso aos clientes através de um ponto bem conhecido;
A única instância tiver de ser extensível através de subclasses, possibilitando aos clientes usar uma instância estendida sem alterar o seu código.
Use o padrão Singleton quando:
For preciso haver apenas uma instância de uma classe, e essa instância tiver que dar acesso aos clientes através de um ponto bem conhecido;
A única instância tiver de ser extensível através de subclasses, possibilitando aos clientes usar uma instância estendida sem alterar o seu código.
Conseqüências:
O padrão Singleton apresenta vários benefícios:
Acesso controlado à instância única: Como a classe Singleton encapsula a sua única instância, possui controle total sobre como e quando os clientes a acessam.
Espaço de nomes reduzido: O padrão Singleton representa uma melhoria em relação ao uso de variáveis globais. Ele evita a poluição do espaço de nomes com variáveis globais que armazenam instâncias únicas.
Permite um refinamento de operações e da representação: A classe Singleton pode ter subclasses e é fácil configurar uma aplicação com uma instância dessa classe estendida. Você pode configurar a aplicação com uma instância da classe de que necessita em tempo de execução.
Permite um número variável de instâncias: O padrão torna fácil mudar de idéia, permitindo mais de uma instância da classe Singleton. Além disso, você pode usar a mesma abordagem para controlar o número de instâncias que a aplicação utiliza. Somente a operação que permite acesso à instância de Singleton necessita ser mudada.
Mais flexível do que operações de classe: Uma outra maneira de empacotar a funcionalidade de um singleton é usando operações de classe. Porém, tal técnica torna difícil mudar um projeto para permitir mais que uma instância de uma classe.
quinta-feira, 17 de abril de 2008
Padrão ADAPTER - Aula 20
Nome do Padrão: ADAPTER
Como vimos durante a aula, O Objetivo do padrão Adapter segundo "GOF" é converter a interface de uma classe em outra interface esperada pelos clientes. Adapter permite a comunicação entre classes que não poderiam trabalhar juntas devido à incompatibilidade de suas interfaces .
Problema: Como enfrentar modificações de bibliotecas terceirizadas, mantendo nossa aplicação sincronizada quanto às alterações essenciais nas funcionalidade e arquitetura.
Solução: Utilizando classes que trabalharão na camada intermediária entre a aplicação cliente e a biblioteca em si. Executando alterações quanto às chamadas de operações para uma correta operação.
Solução: Utilizando classes que trabalharão na camada intermediária entre a aplicação cliente e a biblioteca em si. Executando alterações quanto às chamadas de operações para uma correta operação.
Dois tipos de Adapter
Adaptador de Objetos.
Criamos uma classe intermediaria que servirá como interface entre as chamadas do código cliente e o código da classe. Ele trabalhará basicamente como um "filtro" para as chamadas. Chamamos essa forma de COMPOSIÇÃO.
Adaptador de Classes.
Criamos uma classe que HERDARÁ da classe utilitária e sobrescrevemos ou recriamos o método chamado. Chamamos essa forma de HERANÇA.
A escolha da abordagem de implementação do Adapterserá uma tomada de decisão do Arquiteto de Software e dependerá do contexto da aplicação. Muita cautela nessa hora!
A escolha da abordagem de implementação do Adapterserá uma tomada de decisão do Arquiteto de Software e dependerá do contexto da aplicação. Muita cautela nessa hora!
Quando Usar o Padrão Adapter:
Você quiser usar uma classe existente, mas sua interface não corresponder à interface de que necessita;
Você quiser criar uma classe reutilizável que coopere com classes não-relacionadas ou não-previstas, ou seja, classes que não necessariamente tenham interfaces compatíveis; (Somente para adaptadores de objetos).
Você quiser criar uma classe reutilizável que coopere com classes não-relacionadas ou não-previstas, ou seja, classes que não necessariamente tenham interfaces compatíveis; (Somente para adaptadores de objetos).
Você precisar usar várias subclasses existentes, porém, for impraticável adaptar essas interfaces criando subclasses para cada uma. Um adaptador de objeto pode adaptar a interface da sua classe-mãe.
segunda-feira, 14 de abril de 2008
Aula 19 - Introdução de Padroes GOF
Primeiramente iremos tratar a respeito da idéia do conceito de padrões.
O que é um Padrão?
Podemos dizer que Padrão é: Compromisso documentado, utilizado em comum e repetidas vezes pelas pessoas relacionadas com um determinado trabalho.
Então segundo Gamma, Helm, Vlissides & Johnson, criadores do padrão GOF. descreveram da seguinte forma o conceito:
"Os padrões de projeto são descrições de objetos que
se comunicam e classes que são customizadas para
resolver um problema genérico de design em um
contexto específico"
Um padrão "GoF" também é classificado segundo o seu escopo; de classe ou de objeto. Nos padrões com escopo de classe os relacionamentos que definem este padrão são definidos através de herança e em tempo de compilação. Nos padrões com escopo de objeto o padrão é encontrado no relacionamento entre os objetos definidos em tempo de execução.
Aprender a programar bem com orientação a objetos
Os 23 padrões de projeto “clássicos” utilizam as
melhores práticas em OO para atingir os resultados
desejados
Padrões "GoF" organizados nas suas famílias:
Padrões de criação
Abstract Factory
Builder
Factory Method
Prototype
Singleton
Referencias Bibliográficas
http://pt.wikipedia.org/wiki/Padr%C3%B5es_de_projeto_de_software - 14/04/2008 23h31
O que é um Padrão?
Podemos dizer que Padrão é: Compromisso documentado, utilizado em comum e repetidas vezes pelas pessoas relacionadas com um determinado trabalho.
Então segundo Gamma, Helm, Vlissides & Johnson, criadores do padrão GOF. descreveram da seguinte forma o conceito:
"Os padrões de projeto são descrições de objetos que
se comunicam e classes que são customizadas para
resolver um problema genérico de design em um
contexto específico"
Um padrão "GoF" também é classificado segundo o seu escopo; de classe ou de objeto. Nos padrões com escopo de classe os relacionamentos que definem este padrão são definidos através de herança e em tempo de compilação. Nos padrões com escopo de objeto o padrão é encontrado no relacionamento entre os objetos definidos em tempo de execução.
Aprender a programar bem com orientação a objetos
Os 23 padrões de projeto “clássicos” utilizam as
melhores práticas em OO para atingir os resultados
desejados
Padrões "GoF" organizados nas suas famílias:
Padrões de criação
Abstract Factory
Builder
Factory Method
Prototype
Singleton
Referencias Bibliográficas
http://pt.wikipedia.org/wiki/Padr%C3%B5es_de_projeto_de_software - 14/04/2008 23h31
terça-feira, 1 de abril de 2008
Padrão Controller
* Padrão Controller é um padrão de aplicação que tem como componetes do projeto o objetivo promover uma maior independência.
É muito comum em grandes projetos a existência de complexas regras de negócios e projetos de interfaces rebuscados, e a redução do acoplamento entre os componentes é bastante importante para se atingir maior reusabilidade e mais facilidade de manuntenção sem comprometer todo o sistema. O padrão MVC entra como uma solução, por sinal muito usada em aplicações web, para a construção de sistemas cada vez mais coesos e menos acoplados.
A sigla MVC refere-se às três camadas do padrão, cada uma responsável por funções muito bem definidas. Vamos tratar de cada uma delas mais detalhadamente:
Model: É a camada que contém a lógica da aplicação. É responsável por conter as regras de negócios e, para sistemas persistentes, todo o controle de acesso e tratamento de dados vindos do banco. Recebe as requisições e geram respostas a partir do que foi pedido. Vamos imaginar um sisteminha de blog. Quando queremos cadastrar ou ver algum post, o Model recebe esta requisição, acessa o banco (ou qualquer outra fonte de dados), faz as operações necessárias e retorna a resposta para alguém que saberá tratar. A função dele termina por aí.
View: É a camada de apresentação ao usuário. É a interface que proporcionará a entrada de dados e a visualização das respostas geradas. Em aplicações web é representado pelo HTML que é processado e mostrado pelo navegador. Geralmente contém formulários de entrada de dados e tabelas, grids, etc. para mostrar as respostas. Essa camada não contém lógicas de negócios, portanto todo o processamento é feito pela Model e então a resposta é repassada para o View. No caso do nosso sisteminha de blog, o View representaria a tela de entrada de uma nova postagem ou uma página listando todos os posts feitos recentemente.
Controller: Já falamos de quem recebe as requisições e de quem as manda. Mas temos que concordar que tudo isso viraria uma grande bagunça se não houvesse alguém para organizar tudo isso. Essa é a função do controller. Essa camada funciona como um intermediário entre a camada de apresentação e a camada de negócios. É função do controller (como o própio nome já diz) coodenar o envio e o recebimento de requisições entre o Model e o View.
Baixo Acoplamento
* Problema
Como minimizar dependências e maximizar o reuso?
O acoplamento é uma medida de quão fortemente uma classe está conectada, possui conhecimento ou depende de outra classe
Com fraco acoplamento, uma classe não é dependente de muitas outras classes
Com uma classe possuindo forte acoplamento, temos os seguintes problemas:
Mudanças em uma classe relacionada força mudanças locais à classe
A classe é mais difícil de entender isoladamente
A classe é mais difícil de ser reusada, já que depende da presença de outras classes.
* Solução
Atribuir responsabilidades de forma a minimizar o acoplamento
* Discussão
Minimizar acoplamento é um dos princípios de ouro do projeto OO
Acoplamento se manifesta de várias formas:
X tem um atributo que referencia uma instância de Y
X tem um método que referencia uma instância de Y
Pode ser parâmetro, variável local, objeto retornado pelo método
X é uma subclasse direta ou indireta de Y
X implementa a interface Y
A herança é um tipo de acoplamento particularmente forte
Uma seção futura aprofunda o assunto
Não se deve minimizar acoplamento criando alguns poucos objetos monstruosos (God classes)
Exemplo: todo o comportamento numa classe e outras classes usadas como depósitos passivos de informação
Tipos de acoplamentos (do menos ruim até o pior)
Acoplamento de dados
Acoplamento de controle
Acoplamento de dados globais
Acoplamento de dados internos
segunda-feira, 25 de fevereiro de 2008
Aula do Dia 18 e 19-02-2008
Padrões GRASP
GRASP: General Responsibility Assignment Software
Patterns.
Padrões de análise catalogados por Craig Larman.
Indicam como atribuir responsabilidades a classes da
melhor forma possível.
Úteis na construção de
diagramas de interações
diagramas de classes
Exemplo de Alguns padrões GRASP: Expert, Creator, High Coesion,
Low Coupling, Controller.
COESÃO ALTA.
A coesão é uma medida do quão fortemente relacionadas e focalizadas são as responsabilidades de uma classe.
Uma classe com baixa coesão:
faz muitas coisas não-relacionadas
executa trabalho demais.
Classes não coesas são:
difíceis de compreender
difíceis de reutilizar
difíceis de manter
sensíveis a mudanças.
É extremamente importante assegurar que as responsabilidades atribuídas a cada classe sejam altamente relacionadas.
Em um bom projeto OO, cada classe não deve fazer muito trabalho.
Cada classe deve capturar apenas uma abstração.
Como perceber que a coesão de uma classe está baixa?
Quando alguns atributos começam a depender de outros.
Quando há subgrupos de atributos correlacionados na classe.
ACOPLAMENTO FRACO
O acoplamento é uma medida de quão fortemente uma
classe está conectada a outras classes, tem conhecimento das mesmas ou depende delas.
Uma classe com baixo (fraco) acoplamento não depende de muitas outras.
Uma classe com acoplamento forte é:
mais difícil de compreender isoladamente
mais difícil de reutilizar (seu uso depende da reutilização das outras classes da qual ela depende)
sensível a mudanças nas classes associadas.
Sempre que possível, evite que o envio de mensagens implique na criação de associações redundantes no modelo.
ESPECIALISTA DA INFORMAÇÃO
É o padrão mais usado para atribuir responsabilidades
Problema: dado um comportamento (responsabilidade) a qual classe essa responsabilidade deve ser alocada?
Solução: atribuir essa responsabilidade ao especialista da informação – a classe que tem a informação necessária para satisfazer a responsabilidade.
GRASP: General Responsibility Assignment Software
Patterns.
Padrões de análise catalogados por Craig Larman.
Indicam como atribuir responsabilidades a classes da
melhor forma possível.
Úteis na construção de
diagramas de interações
diagramas de classes
Exemplo de Alguns padrões GRASP: Expert, Creator, High Coesion,
Low Coupling, Controller.
COESÃO ALTA.
A coesão é uma medida do quão fortemente relacionadas e focalizadas são as responsabilidades de uma classe.
Uma classe com baixa coesão:
faz muitas coisas não-relacionadas
executa trabalho demais.
Classes não coesas são:
difíceis de compreender
difíceis de reutilizar
difíceis de manter
sensíveis a mudanças.
É extremamente importante assegurar que as responsabilidades atribuídas a cada classe sejam altamente relacionadas.
Em um bom projeto OO, cada classe não deve fazer muito trabalho.
Cada classe deve capturar apenas uma abstração.
Como perceber que a coesão de uma classe está baixa?
Quando alguns atributos começam a depender de outros.
Quando há subgrupos de atributos correlacionados na classe.
ACOPLAMENTO FRACO
O acoplamento é uma medida de quão fortemente uma
classe está conectada a outras classes, tem conhecimento das mesmas ou depende delas.
Uma classe com baixo (fraco) acoplamento não depende de muitas outras.
Uma classe com acoplamento forte é:
mais difícil de compreender isoladamente
mais difícil de reutilizar (seu uso depende da reutilização das outras classes da qual ela depende)
sensível a mudanças nas classes associadas.
Sempre que possível, evite que o envio de mensagens implique na criação de associações redundantes no modelo.
ESPECIALISTA DA INFORMAÇÃO
É o padrão mais usado para atribuir responsabilidades
Problema: dado um comportamento (responsabilidade) a qual classe essa responsabilidade deve ser alocada?
Solução: atribuir essa responsabilidade ao especialista da informação – a classe que tem a informação necessária para satisfazer a responsabilidade.
Assinar:
Comentários (Atom)
