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;

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.

Aulas 15 e 16 - Projeto Orientado a Objetos

Alta Coesão

Alta coesão indica qual o grau de relacionamento entre os módulos de uma classe, sintonia que há entre eles, o grande problema de se ter uma alta coesão é o gerenciamento da complexidade, deve-se manter esse tipo de coesão, faz com que elimina ligações, reduz métodos sem ligações entre eles, um trabalha sinergia do outro.

Baixa Coesão podemos citar vários problemas encontrados:

Difícil de entender – muitos métodos numa mesma classe;
Difícil de reusar- muitas classes diferentes para gerenciar;
Difícil de manter – dificuldade no entendimento das classes;
Assumir responsabilidade demais – há uma sobrecarga de classes com muitas responsabilidades;

Solução para os problemas relacionados acima:

Cada classe com sua própria responsabilidade, por exemplo, um módulo de venda não tem a responsabilidade de conectar com o Banco não é missão dela.

Temos alguns tipos de coesão:

- Coincidental
- Lógica
- Temporal
- Procedural
- De comunicação
- Sequencial
- Funcional

Conseqüências de Alta Coesão

1 – Melhora o reuso
2 – Sistemas mais fáceis de manter
3 – Melhora o Entendimento
4 – Melhora a granularidade e conseqüentemente aumenta o reuso

Padrão Controlador

Se preocupa com eventos da classe cadidata para tratar isso, normalmente para cada caso de uso tem que ter um controlador, um controlador apenas recebe o evento e passa adiante, delega para alguém.

Aulas 13 e 14 - Projetos Orientado a Objetos

Acoplamento de Controle

Utiliza flags de controle entre os objetos de forma que um controle o outro, para percebemos um acoplamento de controle basta observar quais são as classes que estão acopladas e verificar a característica básica do controle que é justamente a passagem de parâmetros que controla outra classes, no exemplo mostrado em aula, observamos que há uma classe Lâmpada e uma classe Circuito, nesse caso a classe Circuito controla a classe Lâmpada, passando flags de ajuste para executar alguma ação (Ligar, Desligar, Piscar), há também na classe Lâmpada o problema de ajuste do código o código proposto em primeiro momento funciona, mas poderá ser refatorado criando apenas métodos que serão executados a partir de outra classe(Circuito) , em segundo momento decompomos a classe em múltipla operações primitivas, onde criamos um método para cada ação.

Duas soluções para o Acoplamento de Controle:

1º - Decompor a classe em métodos para se tornar mais transparente;
2º - Utilizar tratamento de exceções.

Acoplamento de Dados Globais

Quando dois ou mais objetos compartilham os mesmos dados, todas as classes trabalham com as mesmas coisas, o problema desse acoplamento é que fica escondido, tornando mais difícil perceber o problema.


Acoplamento de Dados Internos


Quando um objeto altera os dados locais de outro, por exemplo, dados protected e public no caso da linguagem Java, para que esse problema se torne mais difícil de acontecer utiliza-se private e métodos assessores e mutatórios para evitar o acoplamento de dados internos, essas duas soluções lembra o encapsulamento de dados.

Aulas 11 e 12 - Projetos Orientado a Objetos

Acoplamento

Pode-se dizer que acoplamento e à medida que dá a dependência de uma classe com outra, é possível identificar um acoplamento quando uma classe está relacionada com outra através de uma associação, agregação, etc, está ramificada em:

- Conhecimento
- Dependência
- Interligação

O que estudamos nas aulas 10 e 11 como utilizar o baixo acoplamento que é uma boa prática de projeto, quanto menor o relacionamento entre as classes melhor é a manutenção, a portabilidade e a reutilização da mesma. O problema de um alto acoplamento, torna difícil o entendimento, a reutilização e a mudança se necessário de um lugar para outro, a solução mais óbvia é aplicar o Baixo Acoplamento.

Podemos citar alguns tipos de Acoplamento:

Acoplamento de dados 1 (-)
Acoplamento de controle 2
Acoplamento de dados Globais 3
Acoplamento de dados Internos 4 (+)

Aulas 9 e 10 - Projeto Orientado a Objetos

Padrões GRASP

- Criador

Nas duas aulas ministradas discutimos o funcionamento do Padrão criador, exemplificando com códigos.

Produto

Public calss produto {

private Integer idProduto;
private String Descricao;
private Double valorUnitario;

public String GetDescricao() {

return descrição;
}

Public void setDescricao (String descricao) {

This.descricao = descircao;
}
}

ItemVenda

Public calss produto {

private Double qtde;
private Produto p;

public void setP(Produto p) {


this.p = p;
}
}

Venda

public class Venda {

private set itemVendaList = new HashSet();
private Data dataVenda;
private Integer idVenda;

public criarItemVenda (Produto P, Dpuble qtde) {

ItemVenda i = new ItemVenda();
i.setP(P);
i.setQtde(qtde);
itemVendaList.add(i);

}

}

No trecho de código está sendo aplicado não só o padrão criador, mas também o especialista, é importante citar também que há um encapsulamento do objeto.

Aulas 7 e 8 - Projetos Orientado a Objetos

Padrões GRASP

· Criador

O padrão guia a atribuição de responsabilidades relacionadas com a criação de objetos.

Padrão criador segue 5 condições básicas para atribuir responsabilidades:

Atribua à classe B a responsabilidade de criar uma nova instância da classe A se uma das seguintes condições for verdadeira:

- B agrega objetos de A
- B contém objetos de A
- B registra instâncias de objetos de A
- B usa objetos de A
- B tem os valores iniciais que serão passados para
objetos de A, quando de sua criação

Objetos agregados, contêineres e registradores são bons candidatos à responsabilidade de criaroutros objetos, algumas vezes o criador é o objeto que conhece os dados iniciais do objeto a ser criado, o ideal é manter o Baixo Acoplamento e a Alta Coesão.

Aulas 5 e 6 - Projetos Orientado a Objetos

Padrões GRASP

· Especialista na Informação
· Criador
· Coesão
· Acoplamento fraco
· Controlador

Especialista na Informação

Aplicam-se padrões para ter uma documentação da boa prática utilizada, catalogada com problemas e soluções, se um nome ao padrão, problema que resolve e solução apresentada para determinado problema, padrões GRASP tem por sua vez atribuir a objetos responsabilidades ao mesmo. De imediato estamos falando do padrão Especialista na Informação, nada mais é do que um conjunto de software responsável por identificar quem detém é responsável pela informação fornecida, o padrão mais utilizado para atribuir responsabilidades, sendo assim como há muita informação espalhada em vários objetos, há em cada objeto um Especialista parcial. Aplicam-se os dois principais métodos conhecer e saber, só assim chegará à solução desejável. O Padrão especialista não está explicito no modelo de Análise ele surgi no modelo de projeto isso não significa que se não houver informação suficiente ele não possa detalhar mais o modelo de análise ao ponto de haver mudança no modelo do projeto. As classes elas deverão ter o conhecimento de suas atribuições e responsabilidades para fornecer tais informações a partir daí outras classes terão acesso.
No padrão Especialista na Informação o encapsulamento é mantido ocultando as informações, pois utiliza suas próprias informações para executar suas responsabilidades, ou seja, as responsabilidades estão juntas com os dados isso faz com que haja um fraco acoplamento e uma alta coesão entre os objetos tornando os sistemas mais robustos e fáceis de manter.

Aulas 3 e 4 - Projetos Orientado a Objetos

Diagramas de Interação

- Colaboração
- Seqüência

Diagrama de colaboração as ligações são feitas de forma simples e, representadas no modo de grafo, os objetos não tem uma localização especifica, a indicação das mensagens neste diagrama é feita através de setas específicas e paralelas à principal (associação), essas mensagens podem ir evoluindo de acordo com o projeto. Para se criar novas instancias é preciso deixar claro utilizando o comando create seguido do estereótipo utilizado na UML. No diagrama de colaboração pode ainda ser criadas condição e iteração, ou seja, se houver necessidade, no caso da iteração para identificá-la será antecedida por um *, na seqüência a condição geralmente um looping.

Diagrama de seqüência são apresentadas através de raias com a finalidade de determinar inicio, meio e fim, as trocas de mensagens entre os objetos são apresentadas de forma clara para que no decorrer do projeto facilite na implementação, se utilizam de métodos e instancias que por sua vez indicam a qual objeto está se relacionando. Através do diagrama de seqüência podemos ter idéia de como ficará o código na prática, uma visão geral de como o código do projeto poderá ficar.
O que são comuns entre os diagramas de Seqüência e Colaboração são as classes e instancias que no projeto irão surgir.

Padrões

Padrões é um conjunto de soluções para o problema nominado, segue referencias, modelos, regras etc. São utilizados para aplicar responsabilidades a cada atribuição, de forma que possam ser respeitados os limites que são impostos a cada uma, por exemplo, só começa a realizar o trabalho logo após que a outra atribuição terminou dentro do estudo de padrões há algumas definições:

- O saber - quando algo tenha o conhecimento de determinado tarefa, atribuição.
- O fazer - diz respeito a obrigatoriedade de fazer, executar a tarefa.

- Granularidade alta quando envolve vários objetos em uma operação.

- Granularidade Baixa quando um objeto é acionado e não depende de outros para execução da tarefa.

Aulas 1 e 2 - Projeto Orientado a Objeto

Análise:

Não tem como falar de Projeto Orientado a Objeto sem antes passarmos por Análise Orientada a Objeto, onde é feito todo o levantamento dos dados que serão utilizados no decorrer do projeto, é na análise que definimos qual caminho que o projeto deverá percorrer, ou seja, quais detalhes, interações e interfaces que o sistema deverá atender aos requisitos que foram levantados a partir da investigação inicial do projeto, partindo desse preceito, saímos da análise para o projeto propriamente dito, chamamos de Transição da Análise para o Projeto.

Projeto:

Não que a análise foi mal elaborada, mas o projeto tem como objetivo ir mais a fundo em suas atribuições, refinando todo levantamento de requisitos que foi realizado pela Análise, na Análise do Projeto serão abordados objetos de software que se interagem, desenvolver o projeto para satisfazer os requisitos se utilizando de métodos e instancias que o projeto será desenvolvido a partir de uma Linguagem OO “JAVA” , Diagramas de Interação (Seqüência ou Colaboração), colaboração entre objetos onde há uma troca de mensagens entre os objetos de um para o outro, se utilizando de métodos que são adotadas na linguagem OO, sem contar que é indispensável o uso da UML para definição de interfaces, classes, domínios, diagramas de seqüência e atividades, tendo a UML como ferramenta de Apoio ao desenvolvimento, as decisões do projeto serão tomadas com maior precisão tornando o projeto mais visível como um todo.