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

Orientação a Aspectos – Anatomia

                O paradgma de programação orientada a aspectos envolve duas etapas. Uma delas é a decomposição do sistema em diversas partes isoladas e não espalhadas. Essa é a parte mais simples de implementar. A outra etapa significa juntar novamente essas partes para obter um sistema desejado. O processo de juntar essas partes pode ser entendido com “composição” já que compõem várias partes antes separadas. Além disso existem três etapas para ser determinadas durante o processo de composição na orientação a aspectos:

               Correspondência: A forma de correspondência da linguagem é o modo com o qual se descreve quais entidades serão compostas entre si. A correspondência pode ser implícita (determinada por regras da linguagem) ou explícita (descrita pelo programador). Por exemplo, no exemplo acima que mostra duas políticas, podemos dizer que há uma correspondência implícita entre eles - os métodos com os mesmos nomes estão relacionados.

                Semântica composicional: é o que deve acontecer com os elementos que correspondem. Em geral, linguagens de POA modificam a semântica das chamadas a métodos:
Em linguagens procedurais, chamar a função F implica em executar a função F.
Em linguagens orientadas a objetos, chamar o método M implica em executar algum método M em uma das subclasses que definem M. 

Em linguagens orientadas a aspectos, chamar o método M pode ter diversas consequências: 

M é executado, ou
N (algum outro método) é executado, ou
M+N são executados, em alguma ordem definida


                   A linguagem pode definir diversas semânticas diferentes que em geral são escolhidas pelo programador. No exemplo da última aula, uma linguagem de POA permitiria que o usuário definisse o que acontece com os métodos que têm o mesmo nome (ou seja, que correspondem): se um for chamado, os dois devem ser executados? em que ordem? apenas um deve ser executado? qual?

                  Tempo de ligação: diz respeito ao momento em que a correspondência passa a surtir efeito; pode ser estático (em tempo de compilação) ou dinâmico (em tempo de execução).

                  A ferramenta ou compilador que faz a composição dos elementos em POA é chamado weaver (tecelão), pois "tece" os vários fragmentos de programa em um programa único.

                  A forma de composição das partes é o que realmente distingue linguagens orientadas a aspectos de outras linguagens. Em linguagens procedurais ou orientadas a objetos, a composição é feita através de chamadas de procedimentos ou métodos. Ou seja, uma parte (por exemplo, uma classe) usa a funcionalidade de outra chamando um método.

                  Em POA, não há chamadas explícitas de métodos entre partes. Ao invés disso, especifica-se, em uma parte separada, como uma parte deve reagir a eventos que acontecem em outra parte. Essa estratégia reduz o acomplamento entre as partes, pois as partes não se acessam diretamente.

Benefícios da programação orientada a aspectos:

· Menos responsabilidades em cada parte
· Melhor modularização
· Evolução facilitada
· Mais possibilidades de reutilização.

Fonte: http://www.aspectos.org/courses/aop.html

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

Padrão de Projeto Expert

         O padrão Expert faz parte dos padrões de projeto classificados como GRASP. O objetivo dele é atribuir determinada responsabilidade a uma classe. Deve ser observada a classe que tem as informações relevantes para desempenhar a responsabilidade.

Tomemos como exemplo um sistema PDV (ponto de venda), onde gostaríamos de atribuir a responsabilidade “cálculo do total de um pedido” à uma classe.  Observamos então, em nosso sistema, qual a classe “expert” das informações necessárias para a obtenção desse total e a ela será delegada essa responsabilidade.

Dentro deste contexto, a classe “expert” do conteúdo relevante à obtenção da informação desejada é a “Pedido”, pois ela possui a lista de produtos que serão utilizados para o cálculo do valor total do pedido. Portanto, a ela será designada a responsabilidade “cálculo do total de um pedido”.

Benefícios:

– Leva a projetos onde o objeto de software faz o que o objeto real faria

– Mantém o encapsulamento e não aumenta o acoplamento, pois utiliza informações próprias

– Distribui o comportamento uniformemente entre as classes do sistema, aumentando a coesão das mesmas

Sinônimos:

– Colocar responsabilidades com os dados

– Aquele que conhece faz

– Quem sabe faz

– Animação

– Fazê-lo eu mesmo

– Colocar os serviços com os atributos que eles utilizam

– Especialista na informação

Referências:

• MURTA, L. G. P. – “Aula Padrões de Projeto GRASP” - Universidade Federal Fluminense  - RJ, 2007

• Craig Larman, 1999, “Utilizando UML e Padrões”, 1ª ed., Prentice-Hall

• Craig Larman, 2007, “Utilizando UML e Padrões”, 3ª ed., Bookman. 

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

Modelagem de Requisitos Orientada a Aspectos

O levantamento de requisites é fator crucial na etapa inicial de desenvolvimento de software. É durante essa etapa que todos ou grande maioria das funcionalidades do sistema são discutidas por isso se exige muito critério durante esse processo por parte dos especialistas para determinar qual a melhor maneira de detectar e determinar quais serão os requisitos iniciais do sistema.

            Mesmo com todas as técnicas utilizadas no processo de levantamento de requisitos essas abordagens ainda são muito imaturas. E necessário um estudo ainda mais minucioso, a questão é, como tratar mais cedo responsabilidades que serão parte de um sistema até o fim, como prever problemas, como modelá-las? Como vincular componentes?

            Para facilitar a fase de levantamento de requisitos propomos um método de integração com características transversais. Esse método é implementado na linguagem de programação orientada a aspectos, uma delas é a AspectJ. Seguindo o modelo da linguagem orientada a aspectos o nosso modelo de levantamento de requisitos tente em separar as responsabilidades em módulos distintos. A intenção é trazer o modelo de programação orientada a aspectos para o levantamento de requisitos, e desta forma isolar responsabilidades de outras partes do sistema, através de um mecanismo que tornará possível o gerenciamento de requisitos de forma transversal.

            A separação das responsabilidades será realizada, através da separação de características e metas. A composição é realizada pelo um mecanismo que gera um modelo único do sistema sendo desenvolvido, facilitando a inclusão e exclusão de características e responsabilidade desse modelo. Além disso, é possível extrair diferentes visões dos modelos separados melhorando assim na hora de modelar, pois, podemos visualizar a aplicação em diferentes perspectivas diferentes durante a modelagem, facilitando a identificação das responsabilidades envolvidas no sistema.

Segue imagem com o método de integração de características.

Fonte: http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER05/lyrene_silva.pdf

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

Padrão de Projeto Mediator

O Mediator é um padrão de projeto pertencente ao conjunto GoF de padrões de projeto. Classificado como padrão comportamental devido a maneira que ele pode alterar seu a execução do software.

                O objetivo do mediator é gerenciar as colaborações entre um grupo de objetos.  Define um objeto que encapsula as interações dentre desse grupo. Foi criado para resolver problemas de comunicação entre classes em um sistema, diminuindo assim a complexidade e o acoplamento. Melhora a leitura e manutenibilidade do programa, que seria muito maior caso não existisse o mediador no projeto, pois as colaborações teriam que ser distribuídas entre as próprias classes, gerando a necessidade de mecher em todas, caso fosse necessário atualizar algo. Com o padrão mediator, a comunicação entre os objetos é encapsulada com um objeto mediador. Isso reduz a dependência entre os objetos que estão se comunicando.

Exemplo em um jogo:

Esse exemplo ilustra o projeto de um jogo de RPG em turnos. Existem 3 classes, “Ken” e “Ryu” representando os lutadores, e a classe “Fight” que é o nosso mediador, responsável por gerenciar as interações entre os lutadores. Em nenhum momento  as classes que estao sendo mediadas conversaram entre si, sempre interagem com o mediador que faz a comunicação entre elas.

Referencias:

•http://abrindoojogo.com.br/padroes-de-projeto-para-games-mediador

•http://imasters.com.br/artigo/21642/dotnet/o-padrao-de-projeto-mediator-na-pratica

•http://s2i.das.ufsc.br/tikiwiki/apresentacoes/padroes_de_projeto.pdf

•http://www.allapplabs.com/java_design_patterns/mediator_pattern.htm

•http://pt.appbrain.com/app/air-control-lite/dk.logisoft.aircontrol

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

Composição de um sistema Orientado a Aspectos

Um sistema que utiliza programação orientada a aspectos é composto dos seguintes componentes:

A linguagem de componentes que deve permitir ao programador escrever programas que implementem as funcionalidades básicas de um sistema, sem precisar prever nada do que será implementado com a linguagem em aspectos. A linguagem de componentes concentra-se na fase de análise de requisitos do sistema, mas precisamente envolvidos com a regra de negócio.

Linguagem de Aspectos: A linguagem de aspectos dever suportar a implementação das propriedades desejadas de forma clara e concisa, fornecendo mecanismos necessários ao programador elabora estruturas que definam como os aspectos serão envolvidos.

Programas de componentes: é um arquivo fonte escrito em determinada linguagem de programação, por exemplo: Java, C, C++, onde o desenvolvedor codifica regra de negócio de acordo com a análise de requisitos.

Um ou mais programas de aspectos: é o arquivo fonte codificado em um linguagem de aspectos como, por exemplo: AspectJ, AspectC entre outras. A ainda a preocupação de determinar qual linguagem de aspectos será utilizada para determinada situação, pois elas tem características diferentes e são aplicadas para tarefas especificas.

Combinador de Aspectos: a sua função é combinar os programas escritos em uma determinada linguagem de componentes, que são as classes onde são determinadas a regra de negócio, com os programas escritos em linguagem de aspectos, as classes aspectos.

Composição de sistemas utilizando programação orientada a aspectos.

Fonte: http://www.inf.furb.br/seminco/2005/artigos/108-vf.pdf

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