Padrão OBSERVER - Aula 21 e 22

Padrão OBSERVER

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.

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?

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."

É 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.

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.

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.

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.

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!

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ê 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.

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

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.

Existem muitos frameworks MVC para as mais diferentes liguagens como o Struts (Java) e o Symfony ou CakePHP (PHP), e muitos outros. Cabe ao desenvolvedor analisar as suas necessidades e ponderar sobre o uso ou não desse padrão.

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