Aulas 31 e 32 - Projeto Orientado a Objetos

Padrões GRASP – Parte 2

Variações Protegidas

Toda aplicação tem pontos de variação, identifique os pontos de variação ou instabilidade prevista, atribuindo responsabilidades para criar uma interface estável em torno deles. Na variação protegida temos as variações evolutivas e as variações corretivas.

Mecanismos de Variações Protegidas

· Agentes (Brokers) – é encarregado de levar as requisições que recebe, localiza qual local de destino e entrega ao local correto.

· Máquinas Virtuais – simulam vários sistemas em um único meio físico, dá maior portabilidade aos sistemas em ambientes instáveis.

· Projetos dirigidos por dados (dataDriver design) – troca de informações entre aplicações através de arquivos configurados por exemplo XML, framework Spring, TomCat, etc.

· Pesquisa de serviços – é ter alguém que forneça serviços, e ter alguém que consome os serviços disponibilizados, podemos citar como exemplo o novo paradigma SOA.

· Projetos dirigidos por interpretadores – são aplicações que interpretam ambientes ou sistemas diferentes, por exemplo JVM, Engine Regras.

· Projetos reflexivos ou de meta-dados – nesse caso reflete o que tem dentro da classe, por exemplo: o normal a se fazer em uma consulta em banco de dados é pesquisar pelo catalogo do banco e não a colunas, se alguém vier a mudar a tabela que está consultando, alterando apenas o nome das colunas, isso irá prejudicar sua consulta, no caso de uma consulta pelo catalogo do banco o problema descrito acima não irá acontecer pois sua consulta irá solicitar ao catalogo que por sua vez possui o índice da tabela que está consultando e assim retornará os dados da coluna relacionada a consulta.

· Acesso Uniforme – não se preocupa com a estrutura da linguagem, não se restringe a propriedades, métodos, procedimentos, etc., tudo é igual seja ele com definições de propriedade, métodos ou procedimentos, exemplos de linguagens que não se preocupa com definições são: linguagem EIFFEL, C#, etc.

· Princípios da substituição de Liskov – como mecanismo de variação protegida a substituição de Liskov prevê que se declararmos classes como interface qualquer classe poderá implementar a superclasse.


Padrão não Fale com Estranhos

Objetivo é evitar o acoplamento indireto, ou seja, que um cliente precise ter conhecimento de objetos indiretos, ou das representações internas de objetos diretamente referenciados. As mensagens podem ser mandadas dentro da própria classe, não pode mandar mensagens para classes diferentes (externas), se sair disso se torna frágil.

§ Objetos referenciados diretamente – “familiares”
§ Objetos referenciados indiretamente – “estranhos”
§ Novas operações serão necessárias nos objetos diretamente referenciados para funcionarem como operações intermediárias.

Restrições para envio de mensagem – se sair do escopo abaixo a classe se torna frágil

· O objeto this
· Um parâmetro do método
· Um atributo de this
· Um elemento de uma coleção que seja de this
· Um objeto criado dentro do método

Por exemplo se um método mandar mensagem para outro método e assim por diante, há uma fragilidade, pois se houver uma cadeia muito longa de métodos um mandando mensagem para outro pode haver quebras e a aplicação pode vir a falhar, isso pode ser resolvido através do padrão não fale com estranhos seguindo seu escopo.


XP – Extreme Programming


XP, ou Extreme programming, é uma metodologia para desenvolvimento de softwares ágil porém com qualidade indicada para projetos cujos requisitos mudem bastante, utilizam desenvolvimento orientado a objetos e tenham uma equipe de até 12 desenvolvedores. XP enfatiza o envolvimento do cliente e promove o trabalho em equipe





Programação Ágil

Na programação Ágil (processos ágeis) a tendência é poder minimizar os riscos no desenvolvimento de softwares.

- Indivíduos e interação entre eles mais que processos e ferramentas;
- Software em funcionamento mais que documentação abrangente;
- Colaboração com o cliente mais que negociação de contratos;
- Responder a mudanças mais que seguir um plano.

4 focos principais

comunicação - ao extremo entre cliente e equipe, decisão mútua do que deve ser feito primeiro e o que pode ser deixado pra depois;
simplicidade - manter a simplicidade através do reuso de código e minimizando a construção de código;
feedback - pequenos releases e testes contínuos como mecanismo de retroalimentação;
coragem - ser honesto em dizer o que pode ser feito e o que não pode ser feito.

12 Práticas XP

• Jogo do Planejamento
• Fases Pequenas
• Metáfora
• Design Simples
• Testes
• Refatoração
• Programação em par
• Propriedade Coletiva
• Integração Contínua
• Semana de 40 horas
• Cliente junto aos desenvolvedores
• Padronização do código

No Extreme Programming há vários procedimentos a ser seguidos de forma que o projeto possa ser desenvolvido com maior agilidade, alguns dos procedimentos as serem seguidos são:

· Valores do XP
· Princípios do XP
· Práticas XP
· Papéis
· Decisões de Negócio
· Decisões Técnicas
· Pequenos releases (atualizações)
· Metáfora
· Design simples
· Testes
· Refatoração
· Programação em Par
· Código coletivo

Bibliografia

Microsoft Corporation Groups, GRASP - Padrões de Software para Atribuição de Responsabilidade Gerais, Disponível em:
<http://groups.msn.com/cafedotnet/grasppadresdesoftware.msnw> Acessado em 11 Jun 2008, 12:11;

Don Wells, Extreme Programming, Disponível em:
<http://www.extremeprogramming.org/map/project.html> Acessado em: 11 Jun 2008, 12:33;

MARTINS, Juliano, XP - Extreme Programming, Disponível em:
<http://jmmwrite.wordpress.com/2008/02/26/xp-extreme-programming/> Acessado em 12 Jun 2008, 13:03;

Instituto Militar de Engenharia – IME Departamento de Engenharia de Computação - DE/9 Cap Mello, Engenharia de Software, Disponível em:
<http://www.des.ime.eb.br/~cgmello/engsw/modulos/A1-ENGSW-Introducao.pdf> Acessado em: 12 Jun 2008; 22:56;

Aulas 29 e 30 - Projeto Orientado a Objetos

Padrões GRASP Parte 2

Invenção Pura

Faz uso das classes de domínio para ser implementada, surge nessa implementação um problema que objeto deve ter a responsabilidade quando você não quer violar "Alta Coesão" e "Baixo Acoplamento". Para resolver esse problema podemos aplicar o conceito de uma classe Artificial ou inventada ela, não é uma classe de domínio por isso podemos associá-la com outras classes que são de domínio para resolver o problema de Alto Acoplamento e Baixa Coesão, atribuindo a ela responsabilidades coesas. Algumas das vantagens são:

· Diminui o Acoplamento;
· Diminui a pulverização de código e,
· Aumenta a coesão

Lembrando que a Invenção Pura nunca vai ser uma classe de Domínio, ela é uma classe inventada, e que possui suas responsabilidades quanto a outras classes, tendo em vista a reusabilidade.


Por exemplo: Conexão Remota





No exemplo acima, podemos observar que as aplicações não estão ligadas diretamente, existem entre elas os objetos artificiais (inventados) que ao se comunicarem ligam uma aplicação à outra,

Indireção

O principal objetivo de se usar Indireção, é que podemos atribuir a responsabilidade a um objeto intermediário que faz mediação entre os outros componentes ou serviços de modo que eles não estejam diretamente acoplados. O objeto intermediário cria uma camada de indireção entre os dois componentes que não dependem um do outro: agora ambos dependem da indireção.

Nesse caso a Indireção pode ser uma classe de domínio, com suas responsabilidades atribuídas onde outras classes fazem uso dela indiretamente.


Por exemplo:

Numa Venda que precisa ser consultado CPF, Cartão de Crédito e Cheque a quem atribuir essas responsabilidades? Devo-lhes dizer que podemos criar uma classe seja ela Inventada ou até mesmo de domínio sendo ela uma classe intermediária, nesse caso ela que teria as operações de consulta fazendo conexão externa e retornando o resultado da consulta para as classes que solicitaram as operações.


Sobre Framework Spring

O Spring é um framework open source criado por Rod Johnson e descrito em seu livro "Expert One-on-One: J2EE Design e Development". Trata-se de um framework não intrusivo, baseado nos padrões de projeto inversão de controle (IoC) e injeção de dependência. Esse framework oferece diversos módulos que podem ser utilizados de acordo com as necessidades do projeto, como módulos voltados para desenvolvimento Web, persistência, acesso remoto e programação orientada a aspectos. Esse framework foi criado para que ele se conecte com outros frameworks, IoC (Inversão de Controle) não é a aplicação que controla, o controle ta fora da aplicação.

O spring traz um framework AOP (Programação Orientada a Aspectos) muito poderoso e totalmente integrado com a BeanFactory utilizada por toda a aplicação, mas não suporta todos os recursos AOP suportados por outras implementações de AOP.

1 - O spring não suporta interceptação de campos, apenas de métodos.
2 - O suporte a AOP do spring implementa as interfaces definidas pela AOP Aliance.
3 - Por default são suportados os seguintes tipos de Advices:

– MethodInterceptor
– ThrowsAdvice
– BeforeAdvice
– AfterReturningAdvice

4 - Um exemplo clássico de utilização transparente do suporte a AOP do spring framework, é o gerenciamento de transações declarativas nativo do Spring, que é implementado como um Advice AOP.
5 - podemos ver também, diversas implementações de logins, controle de exceções, adição de interfaces em objetos.

Bibliografia

Wikimedia Foundation, Inc, Spring Framework, Disponível em: <http://en.wikipedia.org/wiki/Spring_framework> Acessado em 04 Junho 2008, 12:16;

GRASP Patterns, Disponível em:
<http://equipe.nce.ufrj.br/jonas/asi/privado3/Grasp%20Patterns.ppt> Acessado em 04 Junho 2008, 12:59;

ROCHA, Helder, Padrões de Design com aplicações em JAVA, Disponível em:
<http://www.argonavis.com.br/cursos/java/j930/tutorial/Design_Patterns.pdf> Acessado em 04 Junho 2008, 13:33;

NEVES, Tiago Araújo, CONSTRUÇÃO DE UM PROTÓTIPO DE FRAMEWORK PARA OTIMIZAÇÃO E SEU USO PARA A RESOLUÇÃO DO PROBLEMA DE ROTEAMENTO DE VEÍCULOS COM FROTA HETEROGÊNEA E JANELAS DE TEMPO, Disponível em:
<http://www.decom.ufop.br/prof/marcone/Orientacoes/PRVJT-Framework.pdf> Acessado em 05 Junho 2008, 22:45;

INFORMAÇÃO, Estratégia Tecnologia da, Projeto Orientado a Objetos, Disponível em:
<http://www.inf.ufg.br/~juliano/ensino/especializacao/ProjSw2007/ProjetoOO.pdf> Acessado em 05 Junho 2008, 23:17;