SEGUNDO SEMESTRE

Aula 19 Padrões GOF

GOF - Gang of Four (gangue dos quatro).
Nessa aula, nos foi apresentado Design Patterns, ou também conhecido por padrões GOF.
Esses padrões recebem esse apelido por causa de seus quatro criadores (Erich Gamma, John Vlissides, Ralph Jonhson e Richard Helm) e é composto de 23 padrões.
Mas, pra que realmente servem esses padrões?
Esses padrões são um apanhado de procedimentos, teste e documentos que norteiam a maneira de alcançar um objetivo qualquer em engenharia de software.
Com isso temos um programa/código/projeto com maior qualidade e menos suscetível a erros.

Os 23 padrões são:
1 - Adapter
2 - Façade
3 - Composite
4 - bridge
5 - Singleton
6 - Observer
7 - Mediator
8 - Proxy
9 - Chain of Responsibility
10 - Flyweight
11 - Builder
12 - factory Method
13 - Abstract Factory
14 - Prototype
15 - Memento
16 - Template Method
17 - State
18 - Strategy
19 - Command
20 - Interpreter
21 - Decorator
22 - Iterator
23 - Visitor

Aula 20 Adapter
O padrão adapter é um mediador entre classes e interfaces e ou classes e classes.
A melhor maneira de se pensar em adapter é fazer uma analogia com um T ou benjamin. onde o problema é ligar um plugue de tres pinos (2p+t) em uma tomada de dois pinos (2p).
A solução é usar o T para servir de intermédio entre um objeto e outro, mesmo que estremamentes diferentes. é ai que entra o padrão adapter.
A útilização desse padrão é benefica, pois além de fazer objetos distinto "conversarem" entre si, ele ainda evita alto-acoplamento.

Aula 21 Singleton
Ao utilizarmos o padrão singleton determinamos que uma classe só tenha uma instância.
No caso, ela pode ser usada para classes que tratam de uma única conexão com banco de dados, geração de logs, etc.Suas vantagens caracterizam-se por:
Acesso único e centralizado ePode conter subclasses, pelo fato de conter outros métodos e não apenas métodos estáticos.
Desvantagens:Sua principal desvantagem, é que por se tratar de algo que funciona bem e é rápido de se implementar, abre muita margem para gambiarras e código feios. Principalmente com variáveis globais.Dificil de implementar em ambientes distribuídos e multithreaded.Além de ser difícil os testes, visto que pode depender de outras classes para serem executados os mesmos.

Aulas 22, 23 Observer Padrão Observer, como o próprio nome ja diz, server para observar o estado de um objeto.Ao útilizá-lo, temos uma classe que fica em stand-by aguardando a mudança de estado da classe que está sendo observada, com isso ele controla também o momento de acesse dessa classe, através de uma fila.

Aula 24 – Nessa aula, tivemos os seguintes exercícios para queimar pestana... de leve.
01) Um objeto “A” precisa executar um método quando o estado do objeto “B” for alterado. Qual o padrão GOF deve ser usado? Qual o papel do objeto “A” e do objeto “B” nesse padrão?
R: Padrão Observer. Onde “A” é observer e “B” é subject.

02) Qual o padrão GOF devemos usar quando necessitamos executar diversas ações de forma atômica?
R: Padrão Command. que pode fazer e desfazer ações.

03) Uma classe de conexão só pode ter no máximo 10 instâncias. Qual o melhor padrão GOF usar?
R: Singleton.

04) Duas classes “A” e “B” tem interfaces distintas. Qual padrão utilizar se “B” precisar de “A”?R: Padrão Adapter.

05) Quando uma classe de terceiro utiliza uma classe sua, qual padrão usar?
R: Padrão Command.

06) Quais as funções do Model, View e Controller?
R:
 Estado da aplicaçãoModel
 Regra de negócio
 Notificar a View
DAO

 Enviar e receber dados do frameView
 Atualizar dados depois da solicitação
 Atualizar dados da interface gráfica

 Tratar eventos dos casos de usoController
 Seleção do que mostrar na view
Busca e envio de dados para model

Aula 25 Arquitetura MVC
Nessa aula, tivemos a explanação de como é a arquitetura MVC – Model, View e Controll.
Onde:
Model: representa os dados da aplicação e regras de negócio associadas com os dados. Notifica o View sobre alterações.
View: é um Observer para o Model. Notifica o Controller sobre eventos iniciados pelo usuário e lê dados do Model.
Controller: é um Observer para o View. Encapsula lógica de controle que afeta o Model e seleciona View.

Eis um breve exemplo de estrutura MVC utilizada pela SUN Microsys no site java.sun.com/blueprints/patterns/MVC.html .

MVC Também conhecida como Model View Controller
Breve Descrição Vários problemas podem surgir quando aplicações conter uma mistura de código de acesso aos dados, código lógica empresarial, e a apresentação código.
Estas aplicações são difíceis de manter, porque todas as interdependências entre os componentes podem causar efeitos, ondulações fortes, sempre que uma mudança é feita em qualquer lugar. Alto acoplamento classes torna difícil ou impossível de reutilização porque eles dependem de tantas outras classes.
Adicionando novos dados, muitas vezes exige re-implementação ou recortar e colar código lógica empresarial que, em seguida, necessita de manutenção em vários lugares. O acesso aos dados código sofre do mesmo problema, a ser recortada e colada entre os métodos de lógica empresarial.
A MVC padrão resolve esses problemas por dissociar o acesso aos dados, lógica empresarial, e apresentação de dados e de interação do usuário. Descrição pormenorizada
Veja MVC explicação deste padrão arquitetural Exemplo detalhado A arquitectura do Java Pet Store amostra aplicação site aplica o MVC design padrão.

Outros padrões de projeto são combinadas na concepção da arquitetura MVC.
Classe Croquis amostra aplicação componentes arquitetônicos A arquitetura do Java Pet Store site é descrito com mais detalhes no livro Programa Java BluePrints [SSJ02]
Muitas vezes, é capturada em MVC funcionalidades de um quadro que é reutilizado por diferentes aplicações.
A amostra aplicação Web Application Framework extensível é um quadro para a criação de aplicações MVC. Trata-se de uma implementação de MVC para que novas fontes de dados, lógica comercial, dados e opiniões podem ser adicionadas.
A Web Application Framework design é descrito com mais pormenor em
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html. ________________________________________
Copyright © 2002 Sun Microsystems, Inc. Todos os direitos reservados.

26 27 28 Padrão Command Nessas três aulas, foi explicado o padrão command e exposto exemplo de suas funcionalidades.O padrão command tem a tarefa de encapsular uma solicitação como um objeto. Por exemplo quando damos um comando no SQL. O SQL recebe a sintaxe, executa e mostra o resultado, só que efetivamente esse resultado somente será aplicado ao banco assim que se execute o commit. Se quisermos usar rollback, o padrão command ainda poderá ajudar e funcionará, pois a solicitação ainda está encapsulada.

Aula 29 – Exercícios - .... mais algumas pestanas fritas.... Observação: para os visitantes desse blog, as questões abaixo não foram corrigidas, portanto podem conter falhas. Se acaso quiser contribuir, favor postar um comentário com o número da questão e a solução proposta.

1) Suponha que você esteja desenvolvendo uma aplicação que tenha que interagir com uma operadora de cartão de crédito. Cada operadora de cartão oferece uma interface diferente para acesso às suas informações, havendo, portanto, um comportamento similar, porém variado. Você opta por criar objetos adaptadores para cada uma das operadoras de cartão de crédito. Todos os objetos são implementações de uma mesma interface de forma a beneficiar a extensibilidade. De que tipo de padrão GRASP estamos falando?
R: polimorfismo

2) Qual o padrão GRASP que se caracteriza pela chamada decomposição comportamental onde cria-se uma classe, que não faz parte do domínio do problema, apenas para melhorar a coesão e diminuir o acoplamento?
R invenção pura

3) Projetos reflexivos, de pesquisa de serviço e dirigidos por dados são bons exemplos de que tipo de padrão GRASP?
R: variação protegida

4) O padrão “não fale com estranhos” trata das restrições para envio de mensagens a objetos. A(s) seguinte(s) opção(ões) viola(m) esse padrão, quando enviamos uma mensagem para:
a. Um objeto passado como parâmetro.b. Um atributo da própria classe.c. Um objeto criado no próprio método (visibilidade local).d. Um objeto de uma coleção enviada como parâmetro.e. Um objeto obtido de uma fábrica de instâncias.f. Double valor = aluno.obterCurso.obterValorMensalidade();
R: ...

5) O que caracteriza o princípio Aberto-Fechado ?
R: ...

6) Você está projetando uma classe e observa que um método de uma outra classe, que faz um cálculo complexo, pode e deve ser reutilizado na sua classe. Como resolver o problema sem duplicar código?R : adapter.

7) Que tipo de padrão GOF está melhor representado no diagrama abaixo?
R: Padrão Arquitetura M.V.C. ou Sigleton. (Agora deu dúvida).

8) Que padrão Gof resolve os seguintes problemas?• Como controlar (contar) o número de instâncias da classe?• Como armazenar a(s) instância(s)?• Como controlar ou impedir a construção normal? Se for possível usar new e um construtor para criar o objeto, há como limitar instâncias?• Como definir o acesso à um número limitado de instâncias (no caso, uma apenas)?
R: Padrão Sigleton.

9) Quando usar classes Associativas?
R: ...

10) O que é agregação composta? Cite um exemplo.
R: ...

11) O que são associações reflexivas? Cite um exemplo.
R: ...

12) O que são eventos internos, externos e temporais? Para qual desses eventos é mais recomendável modelar um diagrama de estado?
R: ...

13) No padrão “camadas” para que serve, geralmente, a camada de serviços técnicos?R: ...14) Qual a relação entre o padrão Façade e o padrão camadas?
R: ...

15) A figura abaixo representa um problema do mundo real, qual o melhor padrão Gof para resolvê-la?
R: Padrão observer


30 e 31 Polimorfismo Polimorfismo é simples de se entender. É só lembrar da forma de pagamento de um sanduba. O Garçom pergunta: “Qual a forma de pagamento, Sr.?” E você pode pagar com dinheiro, cartão, cheque ou lavando pratos. Não importa a forma de pagamento, no sistema será realizado um pagamento então a estrutura ou lógica será a mesma, pois a classe ‘pagar’ é igual para todos, apesar de serem distintos na prática.Outra coisa que o polimorfismo faz é plug-in, mas esse aí Eu vou ficar devendo.

32 Invenção Pura
No caso da invenção pura temos um paradoxo.Porque paradoxo? Porque estamos falando de padrões e no caso da invenção pura... ele não é totalmente puro... ocorre meio despdronizado.A invenção pura é um padrão que existe para corrigir problemas de desenvolvimento que aparecem no momento em que se está escrevendo o código e com isso temos que criar um uma classe para atender coesão alta e acoplamento fraco, pois se deixássemos como planejado isso poderia não ocorrer.
33 Indireção O padrão da indireção é resumido em uma única frase.“criar um intermediário entre um objeto e outro”.Porque?Para evitar que dois objetos estejam ligados diretamente (alto-acoplamento).Simples, muito útil e funcional.
34 Padrão GRASP - Variações Protegidas Dessa vez... vou ter que pedir ajuda aos universitários.Abaixo segue descrição do nosso companheiro Marcos Vinícius, com seu blog http://mvxx.blogspot.com/2008/06/variaes-protegidas.html

Domingo, 15 de Junho de 2008

Variações Protegidas Blog referente a aula do dia 09/06/2008Variação Protegida Solução das variaçõesProblemaComo que se consegue projetos de maneira que , o que você tenha implementado nesses elementos não prejudiquem a '"boa" execução dos outros?Uma boa solução seria identificar os pontos de variação, atribuir responsabilidades a estes pontos criando uma interface que atue estavelmente entre eles.O princípio básico da VP é manter a flexibilidade e proteção nas aplicações dos sistemas. Ela atua contra essas variações.
Posso dizer como desenvolvedor “verde” ainda que para se obter uma boa VP no começo segue-se alguns princípios como encapsular dados, interfaces e um bom uso do polimorfismo, só que com o tempo e amadurecimento , se aprendem novos mecanismos para proteção contra variações:
Segue abaixo alguns mecanismos de VP
Projetos dirigidos por dados (data-driven designs)
Este projetos englobam técnicas de inserção em código , leitura de valores , inspeção de caminhos de classe , eles são usados para mudar o comportamento do sistema ou talvez impondo padrões em tempo de execução. Ex – XML e WEB-XML.
Pesquisa de Serviço: Ex:(SOA) – Analise Orientada a Serviços
Inclui técnicas como o uso de serviços de atribuição de nomes, um bom exemplo disso é o SOA (Analise Orientada a Serviços).
Proporciona ao cliente uma proteção contras as variações que possam ocorrer na localização dos serviços.
Projetos dirigidos por interpretador:
Um bom exemplo é a JVM, são projetos baseados em regras de uma fonte externa, ou seja é uma máquina virtual onde coloca-se regras dentro dela e ela toma decisões em cima daquelas regras.
Projetos reflexivos:
Ao meu entender funciona da seguinte maneira, funciona como uma substituição de métodos, ou seja , o fato de se apagar um método de uma aplicação não trava o sistema, pois ele é substituído por um método existente.
Acesso Uniforme:
Existente somente em algumas linguagens.
Como posso explicar isso !!!, bom ao meu entender ele valida as denominações dos tipos no código de qualquer maneira , ou seja , vejamos o exemplo abaixo para uma melhor explicação.
Ex: avião.decolar;
“Decolar” no caso acima é aceito de duas formas , tanto como método quanto atributo e é aí que entra o entendimento do acesso uniforme, ele aceita as duas formas.
O C# é um bom exemplo de acesso uniforme , pois ele aceita essa forma de definição.
Princípio da substituição de LISKOV
Introduzido por Bárbara Liskov é resumida da seguinte forma:
Se q(x) é uma propriedade demonstrável dos objetos x de tipo T. Então q(y) deve ser verdadeiro para objetos y de tipo S onde S é um subtipo de T.
Essa visão de subtipo é baseada na noção de substituição, ou seja , se B é um subtipo de A, então os objetos do tipo A, em um programa, podem ser substituídos pelos objetos de tipo B sem que seja necessário alterar as propriedades deste programa.Uma ótima semana a todos e boa sorte na prova de segunda !!!!!BibliografiaLivro: UTILIZANDO UML E PADRÕES - Craig Larmanhttp://pt.wikipedia.org/wiki/Princípio_da_substituição_de_LiskovPostado por mpaiva às 10:15 0 comentários:

35 Desenvolvimento ágil com XP
XP... como o professor falou... “não confundo com o sistema operacional windows”.Xp é a melhor prática para desenvolvimento - que eu considero - com equipes de alto desempenho, pois explora muito a coesão da equipe, o conhecimento técnico e a capacidade de relacionamento.
Por se tratar de equipes pequenas, no máximo 12 pessoas, o rendimento dos trabalhos fluem mais rápido, pois são equipes de programadores sênior em sua maioria.
Os trabalhos feitos com técnicas de XP, são para projetos pequenos, de 1 a 3 meses de duração e com poucas linhas, de 1.000 a 250.000 linhas.
Uma característica forte do XP é a programação em dupla, onde um escreve as linhas e o outro acompanha lendo e ajudando no caso de uma escrita de código errado, dando sugestões, etc.
No caso da equipe, não existe hierarquia, apenas 4 atores. O programadores, Um coach, Um para tratar de questões burocráticas, exemplo prazos, e o cliente, que participa ativamente do trabalho, inclusive estando no local da programação e dando feedback imediato.
Outro ponto interessante do XP é a maneira como os teste da aplicação são feitos.
Os testes são criados antes do código, simulando situações em que o sistema tem que passar.
Se não passar, algo está errado e tem que ser corrigido.
Com isso ganha-se tempo e menos desgaste na hora em que o código entra em produção.

The end.
Ps.: Peço escusas por ter postado tudo em um único bloco. Deixei para repassar as minhas anotações tudo de uma vez.