Problemas com os aspectos

Tudo possui vantagens e desvatagens. E é importante se conhecer as duas faces. Com a programação orietada a aspectos não é diferente. Iremos agora explorar os pontos negativos deste

-Depuração:Ao se usar a orientação a aspectos, não se é possivel depurar erros nos trechos de interceção entre os dois codigos, aspecto e codigo base.Dessa maneira, a eliminação de bug e falhas se torna mais complexa.

-Execução inadvertida de aspect por metodo: Se o programador não souber ou esquecer os pointcuts que os aspectos estão monitorando, os resultados podem ser imprevisiveis.

-Estagio inicial: Esse paradigma ainda não foi completamente estudado, analisado, consolidado, deixando muitas brechas ainda abertas em seus usos.

-Falta de incentivo, metodologias: Esse paradigma é pouco divulgado, não existem muitos incentivos abertos a seu uso, assim como a inexistencia de uma metodogia para seu uso.

-Advices multiplos se referindo a mesmo pointcut: Se varias referencias apontam para o mesmo ponto do programa sem observação atenta, o resultado da execução de ambos é dubia, podendo comprometer o sistema.

-Pointcut duplicado, anonimo, usado em outro aspecto: Todos esses, combinando com a falta de depuração, tambem geram problemas de confusão que podem levar muito tempo para serem encontrados.


Existem mais problemas relacionados a orientação a aspectos que não foi comentada aqui. Mas sabendo destes, cada um pode agora avaliar se vale a pena o uso desse paradigma ou não em seus projetos.

referencias: 
http://pt.wikipedia.org/wiki/Programa%C3%A7%C3%A3o_orientada_a_aspecto
http://www.dextra.com.br/empresa/artigos/aspectprog.htm
http://www.guj.com.br/java/22100-orientacao-a-aspectos-x-padroes-de-projeto/2
http://www.ic.unicamp.br/~rocha/college/src/aop.pdf
http://www.lisha.ufsc.br/teaching/sce/ine6511-2003-2/work/aopj/relatorio.pdf


Postado por: Douglas Viana dos Santos, ADS - 6º periodo

Padrão de Projeto Iterator

Classificado como padrão comportamental da família de padrões GoF, o iterator Fornece uma maneira de acessar seqüencialmente os elementos de um objeto agregado sem expor sua implementação.

Estrutura

Participantes

IteradorIF : define a interface para acessar e percorrer os elementos
IteradorConcreto :

• Implementa a interface Iterator. 
• Mantém o controle da posição corrente no percurso do agregado.

ColecaoIF : define uma interface para a criação de um objeto Iterator.
ColecaoConcreta : implementa a interface de criação do Iterador para retornar uma instância do ConcreteIterador.

Implementação

O exemplo (adaptado [Software Design Patterns, 2005]), ilustrado na Figura 2, é muito simples, basicamente o usuário adiciona dados do tipo String na quantidade que desejar e a qualquer momento pode navegar entre estes dados utilizando os métodos fornecidos pela interface IteradorIF.

A ColecaoConcreta aplicará uma estrutura de dados desconhecida, ou seja, a forma com que ela armazena os objetos não interessará à classe Cliente. ColecaoConcreta poderá utilizar lista ordenadas, listas encadeadas, algum tipo de árvore ou qualquer outra estrutura, entretanto a forma como o cliente fornecerá e posteriormente fará a leitura desta lista de objetos sempre será a mesma.

Referencia:

Software Design Patterns, 2005



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

Padrão de Projeto Composite

Composite é um padrão de projeto de software utilizado para representar um objeto que é constituído pela composição de objetos similares a ele. Neste padrão, o objeto composto possui um conjunto de outros objetos que estão na mesma hierarquia de classes a que ele pertence. O padrão composite é normalmente utilizado para representar listas recorrentes - ou recursivas - de elementos. Além disso, esta forma de representar elementos compostos em uma hierarquia de classes permite que os elementos contidos em um objeto composto sejam tratados como se fossem um único objeto. Desta forma, todos os métodos comuns às classes que representam objetos atômicos da hierarquia poderão ser aplicáveis também ao conjunto de objetos agrupados no objeto composto.

Estrutura

Estrutura do Padrão de Projeto Composite

Consequências

Vantagens: Define a consistência das hierarquias de classes de objetos primitivos e objetos composição. Clientes podem tratar estruturas compostas e objetos individuais uniformemente. Clientes normalmente não sabem (e não deveriam se preocupar) se eles estão tratando com uma folha ou uma composição; Torna mais fácil adicionar novos tipos de Componentes. Novas composições ou subclasses. Folhas trabalham automaticamente com estruturas existentes e código do cliente. Clientes não têm que ser mudados para novas classes de Componentes. Desvantagem: Quando uma composição tem apenas alguns Componentes, você terá de usar uma checagem em tempo de execução para isto.

Implementação

Este exemplo (adaptado [Software Design Patterns, 2005]) do padrão Composite representa uma simulação de sua funcionalidade propriamente dita, ele foi retirado e adaptado do site. É apresentado através na classe Tela dois botões para mostrar todas as folhas e componentes e outro simplesmente para limpar. Também se utiliza o padrão para construir uma estrutura de árvore gráfica composta de nós primitivos (estes nós podem ser substituídos por linhas, círculos, etc) e nós compostos (grupos de elementos que formam elementos mais complexos).

Fonte:

• http://pt.wikipedia.org/wiki/Composite 
• http://www.pg.cefetpr.br/coinf/simone/patterns/composite.php 

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

Padrão de Projeto State

State é um padrão de projeto de software usado para permitir que um objecto altere o seu comportamento quando o seu estado muda. Ao utilizar este padrão, parecerá que o objeto mudou de classe.

O padrão State deve ser utilizado nas seguintes situações:

O comportamento de um objeto depende fortemente do seu estado e ele deve alterar o seu comportamento em tempo de execução dependendo do estado. Os métodos têm instruções condicionais grandes em que as condições dependem do estado do objecto. Este estado é normalmente representado por uma ou mais constantes do tipo enumerado. Frequentemente, vários métodos contém esta mesma estrutura condicional. O padrão State coloca cada ramo da instrução condicional numa classe separada. Desta forma, o estado do objecto pode ser tratado como um objecto ele próprio, o qual pode variar.

Estrutura

Ao modelar um objeto cujo estado é importante, pode-se descobrir que há uma variável que monitora o modo como esse objeto deveria se comportar, dependendo do seu estado. Essa variável pode aparecer em comandos if complexos, em cascata, que focalizam como reagir aos eventos que o objeto pode experimentar.

O padrão State, ilustrado na Figura 1, oferece uma abordagem mais limpa e simples, utilizando uma operação distribuída.

Estrutura do padrão State

Implementação

A implementação de exemplo para o padrão State é um quiz, ou seja, uma seqüência de perguntas com opções de respostas, na qual de acordo com o número de respostas corretas, será retornado uma nota. Neste quiz, é acrescida alguma regra a mais para o cálculo de pontos. Normalmente o número de respostas corretas é proporcional a nota final. No entanto, este quiz introduz um cálculo, considerando a seqüência de perguntas acertadas.

Por exemplo, inicialmente cada pergunta respondida corretamente traz um ganho de cinco pontos sendo este estado definido pela classePontuacao1, mas se o usuário acertar duas em seqüência faz com que o valor da pergunta fique em dez pontos, que é definido pela classePontuacao2. Caso consiga-se acertar cinco perguntas seqüencialmente a resposta correta valerá vinte. Mudanças também ocorrerão quanto a perca de pontos ao errar perguntas e caso peça ajuda.

No exemplo, ilustrado na Figura 2, PontuacaoIF assume o papel da interface de Estado, enquanto Pontuacao1, Pontuacao2 e Pontuacao3são as implementações desta interface.JanelaState é a classe de apresentação para o cliente, enquanto BuscaPergunta é classe que vai buscar em algum lugar as perguntas e respostas para o jogo. Pergunta é classe VO utilizada para o transporte entre BuscaPergunta e JanelaState e fornecida posteriormente paraContexto visando o cálculo total de pontos conquistados com a resposta da determinada pergunta.

Exemplo de aplicação

Código

Download do aplicativo

Download do diagrama

Fonte:

• http://www.pg.cefetpr.br/coinf/simone/patterns/state.php
• http://pt.wikipedia.org/wiki/State

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

Padrão de Projeto Builder

Builder é um padrão de projeto de software que permite a separação da construção de um objeto complexo da sua representação, de forma que o mesmo processo de construção possa criar diferentes representações.


O padrão Builder, da forma como foi descrito no livro Design Patterns: Elements of Reusable Object-Oriented Software, contém os seguintes elementos:

director — constrói um objeto utilizando a interface do builder;
builder — especifica uma interface para um construtor de partes do objeto-produto;
concrete builder — define uma implementação da interface builder, mantém a representação que cria e fornece interface para recuperação do produto;
product — o objeto complexo acabado de construir. Inclui classes que definem as partes constituintes.

Diagrama UML da estrutura do padrão Builder

O padrão Builder pode ser utilizado em uma aplicação que converte o formato RTF para uma série de outros formatos e que permite a inclusão de suporte para conversão para outros formatos, sem a alteração do código fonte do leitor de RTF.

A implementação da solução para esse problema pode ser realizada através de uma classe de leitura (director) associada a uma classe capaz de converter o formato RTF para outra representação (builder). O objeto da classe de leitura lê cada token do texto e executa o método apropriado no objeto de conversão, de acordo com tipo do token. A classe de conversão possui um método para cada tipo de token, incluindo os caracteres comuns, parágrafos, fontes e etc. Para cada formato de texto suportado é criada uma classe de conversão especializada (concrete builder). Um conversor para formato ASCII, por exemplo, poderia ignorar qualquer requisição para converter tokens que não fossem caracteres comuns. Um conversor para o formato PDF, por outro lado, iria processar qualquer requisição para poder converter o estilo, além do texto.

Diagrama

Exemplo de Diagrama em UML para o Padrão Builder.

Código

Este código, escrito na linguagem Java, mostra a implementação do diagrama mostrado acima.

 abstract class ConversorTexto {
        public void converterCaractere(char c) {
                // vazio
        }
 
        public void converterParagrafo() {
                // vazio
        }
 
        public void converterFonte(Fonte f) {
                // vazio
        }
 }
 
 class ConversorPDF extends ConversorTexto {
        public void converterCaractere(char c) {
                System.out.print("Caractere PDF");
        }
 
        public void converterParagrafo() {
                System.out.print("Parágrafo PDF");
        }
 
        public void converterFonte(Fonte f) {
                System.out.print("Fonte PDF");
        }
 }
 
 class ConversorTeX extends ConversorTexto {
        public void converterCaractere(char c) {
                System.out.print("Caractere Tex");
        }
 
        public void converterParagrafo() {
                System.out.print("Paragrafo Tex");
        }
 
        public void converterFonte(Fonte f) {
                System.out.print("Fonte Tex");
        }
 }
 
 class ConversorASCII extends ConversorTexto {
        public void converterCaractere(char c) {
                System.out.print("Caractere ASCII");
        }
 }
 
 class LeitorRTF {
 
        private ConversorTexto conversor;
 
        LeitorRTF(ConversorTexto c) {
                this.conversor = c;
        }
 
        public void lerRTF() {
 
                List<Token> tokens = obterTokensDoTexto();
 
                for (Token t : tokens) {
                        if (t.getTipo() == Token.Tipo.CARACTERE) {
                                conversor.converterCaractere(t.getCaractere());
                        }
                        if (t.getTipo() == Token.Tipo.PARAGRAFO) {
                                conversor.converterParagrafo();
                        }
                        if (t.getTipo() == Token.Tipo.FONTE) {
                                conversor.converterFonte(t.getFonte());
                        }
                }
        }
 }
 
 public class Cliente {
 
        public static void main(String[] args) {
 
                ConversorTexto conversor;
                if (args[0].equals("pdf")) {
                        conversor = new ConversorPDF();
                } else if (args[0].equals("tex")) {
                        conversor = new ConversorTeX();
                } else {
                        conversor = new ConversorASCII();
                }
                LeitorRTF leitor = new LeitorRTF(conversor);
 
                leitor.lerRTF();
        }
 }

A classe Cliente determina, através do parâmetro passado ao programa Java ("pdf" para formato PDF, "tex" para Tex e qualquer outro para ASCII), qual das classes derivadas de ConversorTexto irá utilizar na construção da classe LeitorRTF.

Fonte:

- Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. 1 ed. Estados Unidos da América: Addison-Wesley, 1995. ISBN 0-201-63361-2
- http://pt.wikipedia.org/wiki/Builder

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

Programação Orientada a Aspectos - Um paradigma em evolução

A alguns anos atrás uma metodologia para desenvolvimento de software era a famosa “Dividir para conquistar”, apesar de funcionar, ela trazia consigo alguns problemas de implementação, um exemplo desse problemas, era a existência de várias linhas de código que sobravam e sem nenhum propósito e causando redundância e inconsistências de dados, além da dificuldade de manter de utilizar do artifício de reuso de código.

Devido a esse problemas surgiu-se a necessidade de uma nova abordagem na produção de sistemas de computadores, foi quando surgiu o novo paradigma de programação orientado a objetos, que era baseado em classes e objetos, isso fez com que os problemas desaparecessem , porém, outros surgiram. Hoje mesmo com todos os recursos da orientação a objetos, muitos desenvolvedor ainda sentem dificuldade em implementar certas entidades do mundo real em objetos do sistema. Embora exista fundamento para expressar uma solução como um conjunto de vários objetos, ainda temos funcionalidades que devem ser aplicadas em diversos deles.

Hoje o que sabemos é que o paradigma orientado a objetos consegue suprir quase todas as necessidades em programação, porém ainda não completamente, devido impactos ocorrentes de novas funcionalidades do sistema em determinada etapa do desenvolvimento pode causar problemas de inconsistência na estrutura do sistema, a ocorrência disso dar-se devido a o modelo orientado a objetos ser estático.

O surgimento da Programação Orientada a Aspectos não de maneira nenhuma substituir qualquer paradigma de programação, muito menos o Orientado a Objetos. Ele veio para completá-lo promovendo novas implementações e uma forma de interação diferente, permitindo que novos requerimentos possam ser facilmente agregados ao sistema, e que funcionalidades inerentes a vários objetos sejam facilmente desenvolvidas modularmente. Por isso esses paradigmas se completam devido a modularidade da orientação a aspectos junto com a orientação a objetos.

O AOP também não veio substituir o SOP (Subject Oriented Programming) já que cada um tem propósitos distintos. O SOP tende a tratar as funcionalidades do sistema como subjects. Mais tarde, em outra etapa, todos esses subjects são agrupados para formar o sistema. Embora um subject possa ser definido como um conjunto de objetos que tenham finalidades semelhantes dentro do sistema, o que é muito semelhante a um aspect, eles distinguem-se pelo fato de um aspect ter sua definição dinâmica no nível de instância de um objeto, enquanto o subject é completamente estático.


Fonte: http://javafree.uol.com.br/artigo/6626/AOP-Um-paradigma-de-desenvolvimento-em-evolucao.html


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

Decorator

Padrão de Projeto Decorator

                Pertencente à família de padrões estruturais do conjunto de padrões de projeto GoF, o Decorator, ou Wrapper, tem como finalidade agregar comportamentos a objetos existentes em tempo de execução. Portanto, pode-se utilizar também a definição de que o Decorator agrega responsabilidades adicionais a um objeto dinamicamente, oferecendo uma alternativa flexível ao uso de herança para extender uma funcionalidade.

Intenção

· Acrescentar responsabilidades a um objeto dinamicamente
· Prover alternativa flexível ao uso de subclasses para se estender a funcionalidade de uma classe

Motivação

· Objeto usado possui as funcionalidades básicas, mas é necessários adicionar funcionalidades adicionais a ele que podem ocorrer antes ou depois da funcionalidade básica.
· Funcionalidades devem ser adicionadas em instancias individuais e não na classe.

Consequencias

· Mais flexibilidade do que herança
        o Adição ou remoção de responsabilidades em tempo de execução
        o Adição da mesma propriedade mais de uma vez
· Evita o excesso de funcionalidades nas classes.
· Decorator e seu componente não são idênticos.
        o Comparações tornam-se mais complexas
· Resulta em um design que tem vários pequenos objetos, todos parecidos

Aplicabilidade

· Acrescentar ou remover responsabilidades a objetos individuais dinamicamente, de forma transparente
· Evitar a explosão de subclasses para prover todas as combinações de responsabilidades

Implementação

Outro Exemplo

1.  // a caixa de texto é o componente "decorado"  

2.  JTextArea txt = new JTextArea();  

3.    

4.  // "decora" a caixa de texto com barras de rolagem  

5.  Component comp = new JScrollPane(txt);  

6.    

7.  // adiciona o componente com barras de rolagem no form  

8.  getContentPane().add(comp); 

Referencias:

SILVA, V. T. Padrões de Design. Wikipedia.org. Acessado em 2012



Postado por: Hélio Marcus Torres de Arêa Leão