Command

O command tem como objetivo encapsular uma solicitação com um objeto, permitindo que clientes parametrizem diferentes solicitações, enfileirem ou façam o registro de solicitações e suportem operações que podem ser desfeitas.

Um exemplo de um Portão Eletrônico que possui um controle que faz o portão abrir e fechar. Na figura 2 está a implementação do Portão.

Figura 2 – Classe Portao

A classe portão possui um atributo estado, onde quando for igual a 0, o portão está aberto, enquanto for igual a 1 o portão está fechado. A classe também possui o método abrir que abre o portão e o método fechar que fecha o portão.

Figura 3 – Interface Command

Na figura 3 está representado a interface Command, que possui o método execute e também o método undo, o qual é opcional, porque nem todas as ações possibilitam uma operação de desfazer.

 Figura 4 – Classe AbrirCommand

Na figura 4 é apresentado a classe AbrirCommand, que é um ConcreteCommand, sua funcionalidade é fazer um portão abrir através do método execute. Para isto, a classe traz um atributo do tipo portão, que precisa ser “setado“ através do construtor. Além de abrir o portão essa classe também possibilita desfazer a operação de abrir, através do método undo que faz o oposto do execute, fechando o portão.

Figura 5 – Classe Controle

Na figura 5 é mostrado a classe Controle que é o Invoker, ela armazena Commands e chama o método execute do command. Além disto, ela possui um outro atributo command (ultimoCommand) que armazena o ultimo command que foi usado, através disso, o controle possui um método desfazer que chama o método undo do ultimo command utilizado.

A principal consequência do Command é que ele desacopla o objeto que invoca a operação daquele que sabe como executá-la. Ao visualizar o diagrama de sequência na figura 2 ficará mais claro como isto ocorre.

Figura 6 – Diagrama de Sequência

Primeiro o Client cria um novo Command especificando seu Receiver, em seguida este Command é armazenado em um Invoker. O Invoker quando quer chamar a ação do Receiver, usa o método execute do Command que por sua vez chama a ação do Receiver. Deste modo o Invoker não conhece como funciona a ação e também não conhece o Receiver.

Para conhecer mais sobre o padrão recomendo que baixem o slide disponível, olhem o exemplo implementado e que façam a atividade prática proposta. Também é interessante ler as referências que foram utilizadas para este trabalho.

Referências

GAMMA, Erich; HELM; Richard; JOHSON, Ralph; VLISSIDES, John – Padrões de Projeto – Soluções reutilizáveis de software orientados a objeto .

FREEMAN, Eric – Use a cabeça!: Padrões de Projetos (Design Patterns).

http://pt.wikipedia.org/wiki/Command

http://www.csi.uneb.br/padroes_de_projetos/command_2.html

Postado por: Argemiro Júnior, ADS - 6º Período

Adapter

"Objetivo: converter a interface de uma classe em outra interface esperada pelos clientes. Adapter permite a comunicação entre classes que não  poderiam trabalhar juntas devido à incompatibilidade de suas interfaces." [GoF]

Duas formas de Adapter

Forma 1

• Class Adapter: usa herança múltipla

• Cliente: aplicação que colabora com objetos aderentes à interface Alvo

• Alvo: define a interface requerida pelo Cliente

• ClasseExistente: interface que requer adaptação

• Adaptador (Adapter): adapta a interface do Recurso à interface Alvo

Forma 2

Object Adapter: usa composição

                                

• Única solução se Alvo não for uma interface Java

• Adaptador possui referência para objeto que terá sua interface

adaptada (instância de ClasseExistente).

• Cada método de Alvo chama o(s) método(s) correspondente(s)

na interface adaptada

Quando usar?

• Sempre que for necessário adaptar uma

interface para um cliente

• Class Adapter

• Quando houver uma interface que permita a

implementação estática

• Object Adapter

• Quando menor acoplamento for desejado

• Quando o cliente não usa uma interface Java ou

classe abstrata que possa ser estendida

Fonte:

Padrões Design de Projeto com aplicações em Java (argonavis)

[1][Metsker] Steven John Metsker, Design Patterns Java Workbook.

Addison-Wesley, 2002,

[2][GoF] Erich Gamma et al. Design Patterns: Elements of

Reusable Object-oriented Software. Addison-Wesley, 1994

[3] James W. Cooper. The Design Patterns Java Companion.

http://www.patterndepot.com/put/8/JavaPatterns.htm

[4][Larman] Craig Larman, Applying UML and Patterns, 2nd.

Edition, Prentice-Hall, 2002

[5][EJ] Joshua Bloch, Effective Java Programming Guide, AddisonWesley, 2001

[6][JMM FAQ] Jeremy Manson and Brian Goetz, JSR 133 (Java

Memory Model) FAQ, Feb 200

Postado por: Hélio Marcus, ADS - 6º Período

Desenvolvimento de Aplicações que utilizam conceitos de Tecnologia Adaptativa

     A simplicidade e eficiência sempre foram fatores importantes e cruciais para boas praticam de desenvolvimento de software. Linguagens de programação estão sendo desenvolvidas para essa linha. Desde sempre os desenvolvedores procuram desenvolver linguagens que possibilitem maior flexibilidade na implementação de sistemas, seja ele de qualquer nível de dificuldade. As linguagens chegaram ao conceito de POO (Paradigma de programação orientada a objetos), que possui uma capacidade de trazer “objetos do mundo real” para a programação. Mas apesar de todos os seus recursos que facilitam o desenvolvimento de sistemas complexos, ainda sim existem problemas que a Orientação Objetos deixa a desejar, ela até resolve o problema, mas de uma maneira não muito aconselhável, podendo prejudicar a flexibilidade, entendimento e por fim o reuso do código.

Em 1997, Gregor Kiczales e alguns cientistas do PARC (Xerox Palo Alto Research Center) desenvolveram um novo paradigma de programação o POA (Programação Orientada a Aspectos) com a finalidade solucionar falhas de programação que a POO não conseguia fazer com eficiência. Segundo os criadores, a POA procura separar a parte do sistema que eles chama de interesses das classes e módulos bem definidos a regra de negócio, dessa forma os analistas podem se dedicar a um interesse de forma independente.

            Mas mesmo com os novos recursos oferecidos pela POA, existia a necessidade de uma linguagem que tratasse o sistema como componentes de forma mais inteligente e flexível para mudanças, essa linguagem orientada a componentes pode ser entendida como um paradigma orientado a objetos ou ser uma linguagem estruturada. Um outra característica em aplicações complexas é a de se automatizarem seu comportamento. Dessa forma o uso da programação adaptativa ganha força, permitindo criar e desenvolver sistemas de alta complexidade mas que dividida em vários módulos distintos, tornando-os independentes na aplicação e que podem adaptar-se com facilidade a mudanças de rotina como casos de uso por exemplo.

Fonte: http://lta.poli.usp.br/lta/wta/wta-2012/trabalhos/papers/wta_submission_13


Postado por: Murilo Almeida, ADS - 6º Período

Strategy

                É um padrão comportamental que tem por objetivo apresentar uma interface para classes que contém métodos com o mesmo nome e diferem entre si apenas na implementação dos métodos. Dentro deste contexto, interface é, não apenas classes abstratas marcadas com palavra reservada INTERFACE, mas também para qualquer modelo reutilizável e abstrato, seja explicitamente uma interface ou classe abstrata. Segue um exemplo:

Em uma loja, existem várias promoções ao longo do ano. É criada então uma interface para a promoção que deverá ser implementada nas classes que irão conter o comportamento para a promoção específica:

package com.strategy;

import java.math.BigDecimal;

public interface Promocao {
     BigDecimal desconto();
}

As classes das promoções:

class PromocaoDeNatal implements Promocao {

     @Override
     public BigDecimal desconto() {
          return 10;
     }

}

class PromocaoDiaDosNamorados implements Promocao {

    @Override
    public BigDecimal desconto() {
         return 15;
    }

}

class PromocaoQueimaDeEstoque implements Promocao {

     @Override
     public BigDecimal desconto() {
         return 40;
     }
}

Agora, pode-se simplesmente criar um objeto do tipo da interface e instanciar com o tipo de promoção necessária aquela epoca do ano. Nesse exemplo, assuma que a classe Celular contém um atributo do tipo da interface Promocao e o instancia com PromocaoDeNatal, que é o tipo de promoção que está sendo utilizada no momento.

public class Celular extends Produto {
     public Celular() {
          this.promocao = new PromocaoDeNatal();
     }
}

Fontes:

Padrão de projetos: Strategy – por Robson Farias - http://serpeerless.wordpress.com/2008/06/22/entendendo-o-padrao-de-projetos-strategy/

Sérginho Vittorino – Padrões de Projeto - http://www.youtube.com/user/SerginhoVittorino?feature=watch

Postador por: Hélio Marcus, ADS - 6º Período

Motivos para utilizar ou não programação orientada a aspectos.

Porque utilizar esse paradigma?

Uma das vantagens da Programação orientada a aspectos está na diminuição do tamanho do código dos componentes envolvidos, já que uma parte do código fica na definição dos aspectos, isso torna a complexidade menor tornando um sistema mais simples de implementar e compreender.

Pelo fato de ter sua implementação está centralizada em uma única unidade, as alterações torna-se muito mais simples, sendo assim, não é necessário reescrever várias classes. Dessa forma o código fica muito mais conciso facilitando sua manutenção e seu reuso.

Por que esse paradigma ainda é pouco utilizado?

Apesar de apresentar uma proposta inovadora no desenvolvimento de sistemas, a orientação as aspectos, apesar de está em constante evolução ainda apresenta algumas limitação em determinados aspectos, tais como:

Ainda não existe um padrão claro para se definir o que será ou não um aspecto no desenvolvimento de um software.

A falta de metodologias ainda é um fator limitado desse paradigma.

fonte: 

http://pt.scribd.com/doc/2625512/Programacao-Orientada-a-Aspectos
http://www.ic.unicamp.br/~rocha/college/src/aop.pdf

Postado por: Murilo Almeida, ADS - 6º Periodo

Aspecto na pratica

http://www.youtube.com/watch?v=wPrmGJFu5Dw&feature=player_embedded 

Esse vídeo em inglês descreve de modo simples o funcionamento da programação orientada a aspecto. Como IDE, é utilizada apenas o eclipse. Uma classe “Hello” está criada, com orientação a objeto, e um aspecto “World”, com orientação a aspecto.

Podemos ver que a classe “Hello” possui um método ”sayHello”, que envia como saída uma frase. O aspecto “World” define um ponto de intervenção (pointcut), que foi chamado “greeting”. O comando execution descreve quando esse pointcut irá agir, que será na chamada da classe e metodo vistos anteriormente. O asterisco diz que não importa o tipo de retorno desse método, e os dois pontos que não importa os parâmetros que são pedidos pelo método(*Hello.sayHello(..))

Mas o que vai acontecer quando as diretrizes forem encontradas ? A linha after()returning() :greeting() nos diz que após o encontro dos argumentos, irá executar o que houver dentro do escopo, que é outra mensagem de saída ( “ World !”)

Ao final não importa qual método será chamado na main, pois nesse exemplo eles possuem a mesma assinatura, sendo o parametro pedido indiferente para a execução do pointcut. O aspecto irá ocorrer em ambos os casos.

Postado por: Douglas Viana, ADS – 6º periodo

Bridge (padrão de projeto de software)

Origem: Wikipédia, a enciclopédia livre.

Bridge é um padrão de projeto de software, ou design pattern em inglês, utilizado quando é desejável que uma interface (abstração) possa variar independentemente das suas implementações.

Imagine um sistema gráfico de janelas que deve ser portável para diversas plataformas. Neste sistema são encontrados diversos tipos de janelas, como ícones, diálogos, etc. Estas janelas formam uma hierarquia que contém uma abstração das janelas (classe base). Normalmente, a portabilidade seria obtida criando-se especializações dos tipos de janelas para cada uma das plataformas suportadas. O problema com essa solução reside na complexidade da hierarquia gerada e na dependência de plataforma que existirá nos clientes do sistema.

Através do padrão Bridge, a hierarquia que define os tipos de janelas é separada da hierarquia que contém a implementação. Desta forma todas as operações de Janela são abstratas e suas implementações são escondidas dos clientes.

 Exemplo
O diagrama mostra a solução para o problema citado. Temos duas hierarquias de classes relacionadas: a hierarquia de tipos de janelas (Janela, Icone e Dialogo) e a de implementação nas plataformas suportadas (JanelaImpl, XWindowImpl e MSWindowImpl). O relacionamento entre as interfaces, Janela e JanelaImpl, é a "ponte" que "desacopla" a interface da implementação. Para que um ícone seja desenhado, faz-se uma chamada ao método DesenhaBorda() que por sua vez realiza "n" chamadas ao método DesenhaLinha() da classe XWindowImpl ou MSWindowImpl, dependendo da plataforma desejada.

Exemplo de Diagrama em UML para o Padrão Bridge

Postado por: Hélio Marcus, ADS - 6º Periodo