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;

Aulas 17 e 18 - Projeto Orientado a Objetos

Padrões GOF

Padrão GOF contém 23 padrões e algumas formas de classificação são elas: criação, estrutura e comportamento, sendo que a criação está relacionando na criação propriamente dita na criação do objeto, a estrutura nos mostra as associações entre as classes e objetos e o comportamento divide as responsabilidades entre as classes ou objetos.
Os padrões GOF está voltado também na qualidade de um software usando o conceito de herança, polimorfismo, modularidade, composição e abstração, a alta coesão e o baixo acoplamento é um fator importante nos padrões GOF para satisfazer a qualidade do software.
Metsker classifica os padrões GOF como:

· Interface – é o meio que liga uma classe ou objeto através de um adaptador;

· Responsabilidade – atribui responsabilidade as classes e objetos, também utilizados nos padrões GRASP;

· Construção – e a construção propriamente dita de uma classe, por exemplo: fabricam instâncias Building;

· Operação – parte de métodos das classes;

· Extensão – Extensibilidade, polimorfismo.

Padrão Interface – Adapter

Adapter, também conhecido como Wrapper, é um padrão de projeto de software ou de desenho (do inglês design pattern). Este padrão é utilizado para 'adaptar' a interface de uma classe. O Adapter permite que classes com interfaces incompatíveis possam interagir.
Adapter permite que um objeto cliente utilize serviços de outros objetos com interfaces diferentes por meio de uma interface única


Podemos ter a seguinte situação:

O Cliente precisa comunicar-se com o Adaptado, mas possuem interfaces incompatíveis. Então, ele comunica-se com o Adapter, fazendo a este uma solicitação. O Adapter repassa a solicitação para o Adaptado. O Adaptado precisa então devolver uma resposta para o Cliente, mas novamente não é possível devido à incompatibilidade de interfaces. A solução é enviar a resposta para o Adapter que irá em seguida encaminhá-la para o Cliente, completando assim o ciclo de comunicação. O adapter é encarregado de fazer o meio entre as classes que não se comunicam dando uma flexibilidade as classes que não são compatíveis umas com as outras.

Em seguida podemos observar um código que representa o padrão Adapter:

//Classe Cliente

public class cliente extends Adaptador{

public static void main(String[] args) {

cliente c = new cliente(); c.executa();

}

}

//Classe Adaptador

public class Adaptador {

public void executa(){

Resultado a = new Resultado();

a.metodo();
}

}

//Classe Resultado

public class Resultado {

public void metodo(){

System.out.println("Resultado da Oeracao")

}

}

Nesse caso foi utilizado as classes Cliente, Adaptador e Resultado, para representadar o padrão Adapter.

Bibliografia

Christopher Alexander. A Pattern Language. Estados Unidos da América: Oxford University Press, 1977. ISBN 0195019199

JEEBrasil Padrão de projeto Adapter <http://www.jeebrasil.com.br/mostrar/38> Acessado em 16 de Abr de 2008.

Wikipedia Adapter <http://pt.wikipedia.org/wiki/Adapter> Acessado em 16 de Abr de 2008.