quinta-feira, 29 de março de 2012

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).

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

terça-feira, 27 de março de 2012

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

segunda-feira, 26 de março de 2012

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

quarta-feira, 21 de março de 2012

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

domingo, 18 de março de 2012

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.

sexta-feira, 16 de março de 2012

Aspecto na pratica




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

quinta-feira, 15 de março de 2012

Programação Orientada a Aspectos – Visão Geral do AspectJ

      O elemento principal do AspectJ é o aspecto. Um aspecto se assemelha a uma classe Java e com isso pode ter tudo que uma classe Java possui: atributos, métodos, restrições de acesso. Porém os aspectos podem conter algumas características particulares, existem dois importantes AspectJ são pointcuts ("pontos de corte") e advice("conselhos").

      Os pontos de corte são definições de instantes durante a execução de um programa. Eles denotam onde e quando os aspectos terão efeito no programa como um todo.
Um advice é um comportamento. Ele especifica não só o que será feito, na forma de uma sequência de operações Java, mas também o momento em que serão feitas as operações.

public aspect Cabecalho {
// Ponto de corte
pointcut cabecalho() : call (* Receita.print());
// Advice
before() : cabecalho() {
System.out.println("-------RECEITA DA COZINHA INTELIGENTE-------");
}
}

fonte: http://www.aspectos.org/courses/aulasaop/aula08.html

Postado por: Murilo Almeida, ADS - 6º Periodo

segunda-feira, 12 de março de 2012

Paradigmas e Aspecto

  O que são os tais paradigmas ?

Já foi comentado neste blog sobre o paradigma da programação orientada a aspecto. Mas o que é um paradigma ?
De acordo com o site dicionário Priberam:
"paradigma (grego parádeigma, -atos) s. m.
1. Algo que serve de exemplo geral ou de modelo. = PADRÃO"

O paradigma é uma linha firme de pensamento, uma teoria para resolução de adversidades,um conjunto de conhecimentos que podem ser organizados a uma unica finalidade, um modelo de resolução de problemas
Esclarecido o que significa essa palavra de cunho "culto", vamos a programação

 Paradigmas de programação
Os quatro paradigmas de programação principais são:
·Procedural: Sequencia de comandos que é lida linha por linha, linearmente até seu fim, como na linguagem C
·Declarativo:Descreve-se o problema primeiramente, o algoritmo posterior ira se encaixar como solução. Como exemplo, Prolog
·Funcional:Divide o problema em varios blocos. Estes processam os dados e ao final se combinam, formando o resultado. Como exemplo, Haskell
·Orientado a objetos: Conjunto de classes, os objetos, possuem atributos (variaveis) e metodos(funções). Comunicam-se entre si para chegar ao resultado. Como exemplo, Java
E o discutido nesse blog:
Orientado a aspecto:Usado em conjunto com outro paradigma de programação. É descrito sendo um encapsulador de responsabilidades que aumenta a organização e facilidade na criação e manuntenção do codigo.
Essas capsulas são inseridas no codigo base em pontos bem definidos (join points), Os Join Points podem ser chamados sempre que uma função com uma nomeclatura especifica for processado. Alem disso, os aspectos (agem como classes) podem ser inseridos, alterados ou removidos em tempo de compilação, o que é uma possibilidade interessante.
É considerada uma meta-programação, pois ela deve ser compilada uma primeira vez para gerar um codigo modificado, e com a segunda compilação é que o resultado final surge.
Para ser utilizada são necessarias basicamente: programa dos componentes, programa de aspectos, e um combinador de ambos, chamado "aspect weaver". Este é o primeiro compilador já citado

                                                                                                                                                                                                    



Basicamente, a orientação aspecto funciona como um simbionte. Não vive sem o seu hospedeiro, mas quando estão juntos, ambos obtem diversas vantagens. Para finalizar, dois exemplos de codigo.

Exemplo AspectJ:
public aspect HelloFromAspectJ {
            pointcut mainMethod() : execution(public static void main(String[]));
            after() returning : mainMethod() {
                  System.out.println("Hello World");
            }
      }

Exemplo Delphi prism:
method MyObject.DivideBy(aValue: Integer);
require
 aValue <> 0;
begin
 MyValue := MyValue/aValue;
end;

Postado por: Douglas Viana, ADS - 6º periodo


Referencias:

Façade

Façade
Origem: Wikipédia, a enciclopédia livre.




Em padrões de projeto de software, um façade (fachada em francês) é um objeto que disponibiliza uma interface simplificada para uma das funcionalidades de uma API, por exemplo. Um façade pode:
tornar uma biblioteca de software mais fácil de entender e usar;
tornar o código que utiliza esta biblioteca mais fácil de entender;
reduzir as dependências em relação às características internas de uma biblioteca, trazendo flexibilidade no desenvolvimento do sistema;
envolver uma interface mal desenhada, com uma interface melhor definida.

Um façade é um padrão de projeto (design pattern) do tipo estrutural. Os façades são muito comuns em projeto orientados a objeto. Por exemplo, a biblioteca padrão da linguagem Java contém dúzias de classes para processamento do arquivo fonte de um caractere, geração do seu desenho geométrico e dos pixels que formam este caractere. Entretanto, a maioria dos programadores Java não se preocupam com esses detalhes, pois a biblioteca contém as classes do tipo façade (Font e Graphics) que oferecem métodos simples para as operações relacionadas com fontes.
[editar]Estrutura



Client1, Client2

Usuários da API

Façade

Define uma interface para os packages 1, 2 e 3, isolando-os do resto da aplicação.

O wikilivro Computer Science Design Patterns tem uma página sobreImplementação de façade em diversas linguagens

Esse é um exemplo abstrato de como um cliente ("você") interage com um façade (o "computador") para um sistema complexo (as partes internas do computador como o processador e o disco rígido).

/* Complex parts */
 
class CPU {
    public void freeze() { ... }
    public void jump(long position) { ... }
    public void execute() { ... }
}
 
class Memory {
    public void load(long position, byte[] data) { ... }
}
 
class HardDrive {
    public byte[] read(long lba, int size) { ... }
}
 
/* Facade */
 
class Computer {
    private CPU cpu;
    private Memory memory;
    private HardDrive hardDrive;
 
    public Computer() {
        this.cpu = new CPU();
        this.memory = new Memory();
        this.hardDrive = new HardDrive();
    }
 
    public void startComputer() {
        cpu.freeze();
        memory.load(BOOT_ADDRESS, hardDrive.read(BOOT_SECTOR, SECTOR_SIZE));
        cpu.jump(BOOT_ADDRESS);
        cpu.execute();
    }
}
 
/* Client */
 
class You {
    public static void main(String[] args) {
        Computer facade = new Computer();
 facade.startComputer();
    }
}







Tudo que tivermos no projeto irá ser passado pela fachada que também tem o singleton.
Na fachada chamamos os controladores.

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

segunda-feira, 5 de março de 2012

Singleton

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

Diagrama UML de uma classe singleton.
Singleton, é um padrão de projeto de software (do inglês Design Pattern). Este padrão garante a existência de apenas uma instância de uma classe, mantendo um ponto global de acesso ao seu objeto.

Nota linguística: O termo vem do significado em inglês quando se resta apenas uma carta nas mãos, num jogo de baralho.

Muitos projetos necessitam que algumas classes tenham apenas uma instância. Por exemplo, em uma aplicação que precisa de uma infraestrutura de log de dados, pode-se implementar uma classe no padrão singleton. Desta forma existe apenas um objeto responsável pelo log em toda a aplicação que é acessível unicamente através da classe singleton.





Índice
  [esconder]  1 Onde Usar
 2 Exemplos 2.1 Em Java
 2.2 Em C++
 2.3 Em Delphi
 2.4 Em PHP
 2.5 Em Ruby
 2.6 Em VB.NET
 2.7 Em ActionScript 3
 2.8 Em c# (utilizando Generics)

3 Benefícios
 4 Referências


[editar] Onde Usar

Quando você necessita de somente uma instância da classe, por exemplo, a conexão com banco de dados, vamos supor que você terá que chamar diversas vezes a conexão com o banco de dados em um código na mesma execução, se você instanciar toda vez a classe de banco, haverá grande perda de desempenho, assim usando o padrão singleton, é garantida que nesta execução será instânciada a classe somente uma vez. Lembrando que este pattern é considerado por muitos desenvolvedores um anti-pattern, então, cuidado onde for utilizá-lo. [1]

[editar] Exemplos

[editar] Em Java

Segue um exemplo em Java de uma classe Singleton.


 public final class MySingleton {
     // Instancia estática privada que será acessada
     private static final MySingleton INSTANCE = new MySingleton();

     // Construtor privado. Suprime o construtor público padrao.
     private MySingleton() {
          // Operações de inicialização da classe
     }

     // Método público estático de acesso único ao objeto!
     public static MySingleton getInstance(){
           return INSTANCE;
     }
 }




[editar] Em C++

Segue um exemplo em C++ da implementação de uma classe Singleton:


 class MyClass
 {
    private:
       // atributo estático da "instância única"
       static MyClass *instance = 0;
       //construtor privado, não pode ser utilizado fora da classe
       MyClass() {}

    public:
       // Função-membro que retorna sempre a mesma instância do objeto
       static MyClass& getInstance()
       {
          if (!instance) instance = new MyClass();
          return *instance;
       }
 };




[editar] Em Delphi

Abaixo segue um exemplo de como implementar uma classe Singleton:

Por exemplo, numa classe Fachada, onde se encontra todos os métodos disponíveis para a interface da aplicação, pode ser criado um método dinâmico para que todos os que visualizam essa classe, não criarem mais instâncias da mesma.


 class function TFachada.ObterInstancia: TFachada;
 begin
   If FInstance = nil Then
     FInstance := Cliente.Fachada.TFachada.Create();//objeto instanciado através do Finstance 
   Result := FInstance;//retorna o objeto
 end;




[editar] Em PHP


<?php
class Singleton
{
        private static $_instance;

        // Evita que a classe seja instanciada publicamente
        private function __construct() { }

        // Evita que a classe seja clonada
        private function __clone() { }

        public static function getInstance()
        {
                if (!isset(self::$_instance)) { // Testa se há instância definifa na propriedade, caso sim, a classe não será instanciada novamente.
                        self::$_instance = new self; // o new self cria uma instância da própria classe à própria classe.
                }
                return self::$_instance;
        }
}

[editar] Em Ruby


class Classe
    include Singleton
end

[editar] Em VB.NET


 Public Class MyClass
    Private Shared _instancia As MyClass
    Private Shared objetoSincronia As New Object

    Private Sub New()
    End Sub

    Public Shared Function getInstancia() As MyClass
        If _instancia Is Nothing Then
            SyncLock objetoSincronia
                If _instancia Is Nothing Then _instancia = New MyClass
            End SyncLock
        End If
        Return _instancia
    End Function
 End Class




[editar] Em ActionScript 3


package{
        public class ExemploSingleton {
                private static var instance:ExemploSingleton;

                public function ExemploSingleton(enforcer:SingletonEnforcer) : void {
                        if (enforcer == null)
                                throw new Error("Só pode haver uma instância de ExemploSingleton");
                }

                public static function getInstance() : ExemploSingleton {
                        if (instance == null)
                                instance = new ExemploSingleton( new SingletonEnforcer );
                        return instance;
                }
        }
}
//Para bloquear o acesso ao constructor.
class SingletonEnforcer {

}




[editar] Em c# (utilizando Generics)


public sealed class GenericSingleton<T> where T : class, new()
{
    private static T _instance;

    public static T GetInstance()
    {
        lock (typeof(T))
        {
            if (_instance == null)
                _instance = new T();

            return _instance;
        }
    }
}

// Teste do padrão Singleton
public class Car { public int Color { get; set; } }
public class Person { public string Name { get; set; } }

class Program
{
    static void Main(string[] args)
    {
        Car car = GenericSingleton<Car>.GetInstance();
        car.Color = 1;
        Person per = GenericSingleton<Person>.GetInstance();
        per.Name = "John";

        Car car2 = GenericSingleton<Car>.GetInstance();
        car.Color = 2;
    }
}

Obs: Esta solução não impede a criação de múltiplas instâncias das classes Car e Person. Como a classe genérica GenericSingleton obriga que as classes passadas no parâmetro T tenham um construtor público, é possível criar instâncias em qualquer trecho de código através de construções do tipo: Car car3 = new Car();.

[editar] Benefícios
 Permite o controle sobre como e quando os clientes acessam a instância.
 Várias classes singleton podem obedecer uma mesma interface, permitindo assim que um singleton em particular seja escolhido para trabalhar com uma determinada aplicação em tempo de execução.
 Com apenas uma implementação interna do singleton pode-se fazer com que o singleton crie um número controlado de instâncias.
 É mais flexível que métodos estáticos por permitir o polimorfismo.

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

Entendendo a Programação Orientada a Aspectos



A Programação Orientada a Aspectos - Aspect-Oriented Programming ou simplesmente AOP - foi introduzida em 1996 por Gregor Kickzales, quando estava no Xerox Palo Alto Research Center.


A AOP, assim como a Programação Orientada a Objetos (Object-Oriented Programming ou OOP), introduz um novo paradigma e um conjunto de diretrizes para facilitar o desenvolvimento de software. Ela pode ser vista como um estilo de programação, por abordar de maneira mais elegante questões que poderiam ser resolvidas de outras formas.


A AOP lida com um problema específico: capturar unidades consistentes de um sistema de software que as limitações dos modelos de programação tradicionais forçam a ficar espalhados por diversos pontos do sistema.


Para entender o espírito da AOP, temos que entender alguns conceitos fundamentais.
· Responsabilidades (concerns)






o Sistemas de software consistem de um conjunto de "áreas de interesse" ou responsabilidades distintas como, por exemplo, responsabilidades funcionais (lógica de negócio) e não-funcionais (performance, persistência de dados, logging, autenticação de usuários, segurança, verificação de erros, etc.). Existem também as preocupações relacionadas com o processo de desenvolvimento de software, como clareza de entendimento, facilidade de manutenção, rastreabilidade, simplicidade de evolução do software, etc.




· Separação de responsabilidades (separation of concerns)






o A melhor maneira de se projetar um sistema é através da separação de suas responsabilidades distintas de tal modo que podemos alterar/re-projetar cada uma sem que isto afete as demais partes do sistema. A eficiência do desenvolvimento aumenta na medida em que conseguimos separar as suas diferentes responsabilidades em módulos estanques. Este princípio é razoavelmente antigo, e a OOP nos trouxe uma importante resposta a ele: a classe como uma dimensão para a decomposição de responsabilidades. Mas algumas responsabilidades não são tão facilmente decompostas em apenas uma dimensão...








· AspectJ






o O AspectJ é uma ferramenta open source que acrescenta os conceitos de AOP à linguagem Java, através de uma extensão à linguagem: os "aspects". Ele utiliza Java como a linguagem para a implementação dos concerns individuais, e tem construções para a especificação das regras de weaving, que são especificadas em termos de join points, pointcuts e advices, e tudo isto é encapsulado em um aspect.


o Join points: representam pontos bem definidos na execução de um programa onde um determinado aspecto pode ser aplicado. Em AspectJ, join points podem ser chamadas de métodos, acessos a membros de uma classe, etc. Join points podem conter outros join points.


o Pointcuts: pointcut é um agrupamento de join points baseando-se em um critério pré-definido.


o Advices: trechos de código que são executados nos pointcuts. Um advice contém as alterações que devem ser aplicadas ortogonalmente ao sistema.


o Aspects: são similares a classes: têm um tipo, podem ser estendidos, podem ser abstratos ou concretos e podem conter campos, métodos e tipos como membros. Mas são diferentes de classes: não têm construtor nem destrutor, não podem ser criados com o operador "new", podem conter pointcuts e advices como membros e podem acessar membros de outros tipos.




· Conclusão






o A aplicação de técnicas de OOP para a implementação dos crosscutting concerns resulta em sistemas que são trabalhosos para implementar, difíceis de entender e manter, e também dificultam a evolução do sistema pois pequenas modificações na especificação podem resultar em intervenções em um grande número de classes.


o Utilizando a AOP, pode-se criar implementações que são fáceis de desenhar, entender e manter. Deste modo, AOP traz maior produtividade, qualidade e facilidade para a implementação de novas funcionalidades.


o Acreditamos que os conceitos relacionados com aspectos estão na sua infância. Muito trabalho de pesquisa ainda está sendo realizado sobre o assunto, mas, apesar disto, já podemos tirar proveito prático deste novo paradigma de programação com o AspectJ.






fonte: http://www.dextra.com.br/empresa/artigos/aspectprog.html


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

domingo, 4 de março de 2012

Entendendo o padrão de projeto MVC

MVC é o acrônimo para Model View Controller ou Modelo Visualização Controle , padrão de projeto de arquitetura voltado à orientação de objetos, que tem como objetivo separar a lógica de negócios ( Model ) da interface de usuário ( View ) e do fluxo da aplicação ( Controller ), permitindo o desenvolvimento, teste e manutenção isolada de ambos. O MVC   também permite a reutilização de uma mesma lógica de negócios através de várias interfaces sem que, para isso, seja necessário efetuar grandes alterações no código.
Para que isso seja possível, o desenvolvimento de uma aplicação é feita em camadas, cada uma com funções distintas, porém fundamentais e que interagem entre si. Para melhor entendimento vamos descrevê-las suscintamente.
Crédito da imagem: DCC FC
A camada Model é responsável por grande parte do código escrito. É nesta camada que a lógica de negócios estará presete, com o objetivo de definir e gerenciar toda a informação, bem como a notificação sobre possíveis mudanças ocorridas nos dados, como por exemplo, o estado de uma caixa de texto ou a indicação de ativação de um checkbox.
A camada View compreende a interface de usuário e é responsável pelo acesso aos dados contidos em Model e especifica como estes dados colhidos serão apresentados ao usuário, como, por exemplo, um texto dentro de uma textbox.
Por fim, a camada Controller é reponsável pelo fluxo da aplicação, ou seja, assume o mapeamento das ações efetuadas pelo usuário na camada View , por meio de eventos e, com isso, permite que a camada Model seja alterada.

Créditos da Imagem: CFGigolô
Esta arquitetura, representada em três camadas objetiva simplesmente separar a informação da apresentação, de modo que a manutenção seja funcional, pois o modelo mantém a persistência do negócio, uma vez que as funcionalidades da aplicação econtram-se encapsuladas.

Criar uma aplicação utilizando o modelo MVC implica vantagens e desvantagens entre as quais podemos citar:
VANTAGENS:
  1. Fácil gerenciamento e manutenção;
  2. Independência entre camadas;
  3. Gerenciamento de múltiplas interfaces utilizando um mesmo modelo.
DESVANTAGENS:
  1. Não recomendado para aplicações de pequeno porte;
  2. Exige tempo para análise e modelagem do sistema;
  3. Demanda profissional com conhecimento espceializado. 
    Atualmente o mercado de trabalho em TI sofre com a baixa quantidade de profissionais especializados neste padrão de projeto.

    fonte: http://www.blogomoura.com/2011/07/entendendo-o-padrao-de-projeto-mvc/


    O Projeto VitrineCaruaru segue o padrão MVC para simplificar o entendimento e também pela eficiencia. Como nosso projeto é web, sempre haverá alterações de código, com esse padrão torna-se muito simples para os integrantes da equipe. Fugindo do assunto, outra vantagem também é o reaproveitamento de código.

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