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;

Aulas 27 e 28 - Projeto Orientado a Objetos

Padrões GRASP – Parte 2

Polimorfismo - Strategy

O polimorfismo torna o código mais legível, mais enxuto e facilita a manutenção dos sistemas pois permite que se utilize métodos com o mesmo nome para objetos diferentes. A mesma operação, que foi implementada através da codificação de um método, pode atuar de modo diferente em classes diferentes.

O objetivo principal do polimorfismo é:

1º - Evitar a condição IF e ELSE
2º - Usar polimorfismo melhorar a conectividade dos componentes

A solução de alguns problemas do polimorfismo tais como criar componentes de softwares conectáveis, é atribuir responsabilidade aos tipos para os quais o comportamento varia, usando operações polimórficos.

Ferramentas

Framework e uma biblioteca, ou conjunto de componentes extensíveis que sua aplicação utiliza para estender funcionalidades já pré-desenvolvidas. Cada um e especifico para uma determinada finalidade, por exemplo: Hibernate (Persistencia), Struts(framework web), JUnit(Testes unitários), Log4J(Logs da app), etc...

ToolKit – ferramenta que não obriga o desenvolvedor a seguir um roteiro pré-definido, podendo ser alterado conforme a necessidade de cada aplicação.

Framework – ao contrário da ferramenta ToolKit no framework o desenvolvedor terá que utilizar o roteiro do jeito que está definido na ferramenta, existem vários tipos de frameworks, alguns deles são:

- Spring
- Hibernate
- Log4j
...
-Struts2

- Dojo
- Backbase etc..

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.


Hibernate

Torna a aplicação maleável a mais de um tipo de banco de dados, em poucos minutos de uma reconfiguração básica do framework. Ele também deixa transparente as operações básicas de inserção, recuperação, atualização e remoção de dados. A principal característica está no paradigma de Orientação a Objetos para banco de dados.

LOG4J

Suas principais características está a possibilidade de habilitar ou desabilitar suas atividades de log sem a necessidade de recompilar o código fonte do programa e da sua performance aprimorada. Além dessas características a ferramenta dispõe de logs de acesso ao servidor, estatística de utilização, verifica quais os clientes conectados, resumindo cria-se um log das ações do usuário com relação a aplicação.



Bibliografia

Jacques Philippe Sauvé, Disponível em:<http://walfredo.dsc.ufcg.edu.br/cursos/2002/progII20021/aulas/o_que_e_polimorfismo.htm> Acessado em: 28 Maio 2008, 12:23;

Disponível em: <http://w3.ualg.pt/~hdaniel/poo/teorica/poot03.pdf> Acessado em: 28 Maio 2008, 13:03;

iMasters FFPA Informática Ltda, Disponível em: <http://imasters.uol.com.br/artigo/4497/spring_framework_introducao> Acessado em 28 Maio 2008, 13:53;

Contegix, Disponível em: <http://www.springframework.org/> Acessado em: 29 Maio 2008, 12:10;

Hibernate, Disponível em: <http://www.hibernate.org/> Acessado em 29 Maio 2008, 12:58;

PADILHA JUNIOR, Nilseu Perside Ortiz, RFWNET: FRAMEWORK JAVA PARA CONSTRUÇÃO DE APLICAÇÕES CLIENTESERVIDOR PARA UMA REDE TCP/IP, Disponível em: <http://www.ulbra.tche.br/~tcc-canoas/2003-2/nilseu.pdf> Acessado em: 29 Maio 2008, 13:22;

Aulas 25 e 26 - Projeto Orientado a Objetos

Padrão MVC

Introdução ao Modelo-Vista-Controlador

O MVC é uma estrutura padrão de software que pode ser usada para organizar o código de forma que a lógica de trabalho fique separada da apresentação dos dados.
Existem três partes principais num componente MVC. Estas são, obviamente, um modelo, uma vista e um controlador.

Model

O Model é a parte do componente que encapsula os dados da aplicação. Na maioria das vezes vai fornecer rotinas para administrar e manipular dados. O model deve conter métodos para adicionar, eliminar e atualizar informações na base de dados. Também deve conter métodos para obter a lista existente. De modo geral, a técnica de acesso aos dados deve ser encapsulada no model. Desta forma, se uma aplicação for transferida de um sistema que usa banco de dados para um sistema que usa arquivos texto para guardar as informações, o único elemento que precisa ser alterado será o model - a View e o Controller não precisam ser modificados.

Objetivo:

1. Notificar a View quando seofrer alteração (Padrão Observer);
2. Armazenar o estado da aplicação;
3. Armazenar as Regras de Negócio;

View

A view é a parte do componente usada para transformar e preparar os dados do model para que possam ser apresentados de alguma forma, geralmente o controller retira os dados do model e os entrega para a view. Esta, por sua vez, alimenta templates com estes dados para que possam ser apresentados ao usuário. A view não modifica os dados de nenhuma forma, apenas os apresenta.

Objetivo:

1. Enviar os dados para Frame;
2. Receber os dados e as ações do usuário/Frame;
3. Ao ser notificada pelo Model, solicitar so Controller a atualização dos dados;
   

Controller

O controller é responsável pelas respostas às ações dos usuários. No caso de uma aplicação web, uma ação de usuário (geralmente) é a solicitação de uma página. O controller vai determinar qual solicitação foi feita e vai responder de acordo, fazendo com que o model manipule os dados necessários para depois passá-los para a view para que possam ser mostrados. Considere o controller como o jogador de meio de campo.

Objetivo:

1. Tratar os eventos da View;
2. Selecionar o que mostrar na View;
   

Problema

- Interfaces com o usuário são sensíveis a mudanças;
- O usuário está sempre querendo mudar funcionalidades e a interface das aplicações. Se o sistema não suporta estas mudanças, temos um grande problema!
- A aplicação pode ter que ser implementada em outra plataforma;
- A mesma aplicação possui diferentes requisitos dependendo do usuário;


Bibliografia

Model-View-Controller (MVC) <http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/arqu/mvc/mvc.htm> Acessado em 13 de Maio de 2008, 11:36;

MVC <http://pt.wikipedia.org/wiki/MVC> Acessado em 13 de Maio de 2008, 12:11;

Padrões de Projeto : O modelo MVC - Model View Controller <http://www.macoratti.net/vbn_mvc.htm> Acessado em 13 de Maio de 2008, 13:21;

Aulas 23 e 24 - Projeto Orientado a Objetos

Padrão Command

O padrão command também conhecido como Action ou Transaction, encapsula uma requisição como um objeto, tem como objetivo enfileirar requisições, gerar logs de comando executados, permite desfazer o que foi feito ou executado esse procedimento é também conhecido como RollBack e por fim, faz uso de classes de terceiros permitindo o uso de métodos que não foi você que criou, ou seja, na sua classe você pode utilizar outras classes ou métodos que estão criados há algum tempo, o padrão command nos permite essa flexibilidade e reusabilidade, a vantagem é poder reduzir o acoplamento entre as requisições dos clientes e os objetos que as executam.

Alguns padrões estão relacionados com o Command:

• Composite pode ser usado para implementar MacroCommands.
• Memento pode manter estados que o comando necessita para desfazer o seu efeito.
• Um comando que deve ser copiado antes de ser colocado na lista histórica funciona como um Prototype.

Além dos padrões que foram relacionados acima, podemos citar outros que no decorrer da implementação irão surgindo de acordo com a necessidade, podendo aparecer o padrão Observer, Adapter, etc., de uma forma geral os padrões estão relacionados uns com outros tornando assim a interação entre eles.

Por exemplo:

Um frame com um botão que executa alguma coisa.

1. Criar uma classe que implementa a interface actionListener;
2. Dar corpo a actionPerformed() {

}

3. Adicionar a classe a lista do botão;

Aplicação

De acordo com o site [2] Wikipedia pode-se afirmar que:

“A chave deste padrão é uma classe abstrata Command, a qual declara uma interface para execução de operações. Na sua forma mais simples, esta interface inclui uma operação abstrata Execute. As subclasses concretas de Command especificam um par receptoração através do armazenamento do receptor como uma variável de instância e pela implementação do Execute para invocar a solicitação. O receptor tem o conhecimento necessário para poder executar a solicitação.”

Bibliografia:

[1] Command http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/pat/command.htm - Acessado em 07 Maio 2008, 12:42;

[2] Command http://pt.wikipedia.org/wiki/Command - Acessado em 07 Maio 2008, 13:36;

[3] Padrões de Projeto http://www.etecnologia.com.br/Padrao%20Projeto%20Command.pdf – Acessado em 07 Maio 2008, 13:10;

Aulas 21 e 22 - Projeto Orientado a Objetos

Padrão GOF - Observer

Observador define uma dependência 1- para-n entres objetos, de modo que quando o estado de um objeto é alterado todos seus dependentes são notificados e atualizados automaticamente. Suponhamos que você deseja fornecer várias visões distintas de um mesmo objeto que funciona como um repositório de dados, cada visão é criada por um objeto observador independente, caso cada observador seja diretamente conectado ao repositório, isto criará uma dependência do repositório com relação aos diferentes observadores, o que lhe reduzirá a reusabilidade e flexibilidade. O padrão Observer descreve uma forma de manutenção destes relacionamentos de modo que observadores e repositórios sejam facilmente substituídos.


Situação 1:

Para diminuir o acoplamento entre as classes podemos criar classes abstratas e de Interface, que permitirão o baixo acoplamento entre elas.


Situação 2:

Um observador possui 3 métodos importantes são eles:

1. Método Add ();
2. Método Remove ();
3. Método Notify();

O padrão observer faz parte do MVC (Model View Controller), quando uma situação é alterada o sujeito Model notifica a View que o estado foi alterado, ou até mesmo Controller pode ter a mesma função do Model, pois nele é que ocorrem os eventos do Sistema, dessa forma também pode notificar a View de possíveis mudanças.

No padrão Observer há vantagens e Desvantagem que podemos citar:

Vantagem – Atualização (Refresh) constante;

Desvantagem – Performance na aplicação se houver muitos observadores torna-se inviável.



Bibliografia

DevMedia Java Magazine – O padrão Observer e Swing,
http://www.devmedia.com.br/articles/viewcomp.asp?comp=5719 Acessado em 01 Maio 2008, 11:20;

Observer (Padrão de Desenho)
https://www.l2f.inesc-id.pt/~david/wiki/index.php/Observer_(padrão_de_desenho) Acessado em 01 Maio 2008, 09:30

Wikipedia – Observer http://pt.wikipedia.org/wiki/Observer - Acessado em 01 Maio 2008, 10:03;

Aulas 19 e 20 - Projeto Orientado a Objetos

Padrão Singleton

O padrão Singleton assegura que apenas uma única instância daquela classe vai existir. Por exemplo, seu sistema pode ter apenas um gerenciador de janelas, ou gerenciador de impressão, ou então um único ponto de acesso ao banco de dados. A maneira mais fácil de fazer uma classe que possua uma única instância dela mesma é utilizar uma variável estática na classe, onde será guardada a referência para a instância corrente. No caso do Singleton, a classe deve ter um construtor private, ou seja, ela não poderá ser instanciada diretamente, mas sim fornecer um método comum para que a instância única da classe seja retornada. Cada vez que esse método for chamado, ele deve checar se já existe uma instância da classe e retorná-la, caso contrário ele deve instanciar a classe, guardar a referência ao objeto no atributo estático da classe e então retorná-lo

public class Singleton {

private static Singleton instance;

private Singleton() { }
public static Singleton getInstance() {

if (instance == null) instance = new Singleton();
return instance;
}
}

O código acima pode ser problemático em ambientes multi-threads, ou seja, ele não é uma solução thread-safe. Se uma thread chamar o método getInstance() e for interrompida antes de realizar a instanciação, uma outra thread poderá chamar o método e realizar a instanciação. Neste caso, duas instâncias serão construídas, o que fere os requisitos do singleton.

Utilizando atributo Synchronized

Uma solução para este problema seria utilizar o atributo synchronized em getInstance(), como visto no código abaixo, para que uma outra thread não possa acessá-lo até que a thread que o acessou pela primeira vez tenha terminado de executar.

public class Singleton {
private static Singleton instance; private Singleton() { }
public static synchronized Singleton getInstance()
{ if (instance == null) instance = new Singleton();
return instance;
}
}

Problemas com Synchronized

O problema com o synchronized é que a sincronização é bastante custosa. Estima-se que métodos sincronizados sejam cerca de cem vezes mais lentos que métodos não sincronizados.Uma alternativa simples, rápida e thread-safe é a instanciação do singleton assim que ele for declarado.

public class Singleton {

private static Singleton instance = new Singleton(); private Singleton() { }
public static Singleton getInstance() {
return instance;
}
}


Bibliografia

Marcoratti - O padrão Singleton <http://www.macoratti.net/net_psgt.htm> Acessado em 23 Abr 2008, 13:31;

Universia - Padrões de Projeto <http://www.universia.com.br/mit/6/6.170/pdf/6.170_lecture-12.pdf> Acessado em 23 Abr 2008, 13:25;

Wikipedia Singleton <http://pt.wikipedia.org/wiki/Singleton> Acessadp e 23 Abr 2008, 13:55;