Padrão OBSERVER

Aplicação dos Design Patterns de forma simplificada!

O padrão Observer, é utilizado para quando você precisa encapsular objetos que você não conhece, dentro de um outro e notificá-los após uma determinada ação.

Pré-Requisitos:

Entendimento de orientação à objetos;
Capacidade de abstração;


Situações

Você precisa de um log de ações no seu sistema administrativo;
Você precisa saber quando alguém executou os comandos do seu WebService;
Quando um visitante do seu site fizer cadastro, deve inicializar todas as tabelas relacionadas;


Motivações

Tradicionalmente, aconselha-se o uso de padrões de projeto, pois são uma maneira unificada de falar de um determinado algoritmo;

Segundo estudos, é um padrão com nível máximo de uso;
O .NET Framework utiliza em seus componentes;

Encapsulamento e entendimento simples e fácil;
Utilização correta da orientação à objetos;

Para utilizar o padrão observer, você deve pensar que um objeto, que chamarei de "Subject", irá executar uma ação que outros deverão capturar, que chamarei de "Observer". Veja a demonstração na UML abaixo:



Quando usar o padrão Observer?

Quando uma abstração tem dois aspectos, um dependente do outro. Encapsular tais aspectos em objetos separados permite que variem e sejam reusados separadamente
Quando uma mudança a um objeto requer mudanças a outros e você não sabe quantos outros objetos devem mudar
Quando um objeto deve ser capaz de avisar outros sem fazer suposições sobre quem são os objetos.
Em outras palavras, sem criar um acoplamento forte entre os objetos.


Link Referência

Padrão Singleton

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

2) Singleton é um design pattern (padrão de projeto) que tem o objetivo garantir que existe apenas uma instancia de uma certa classe a qualquer instante e em qualquer ponto de um sistema.

Um singleton é um objeto e como tal é o encapsulamento de dados e comportamento. Não é possivel substituir singleton por nenhum outro padrão de projeto. Mas talvez você não esteja precisando de um objeto único e sim de uma forma global de acessar a ele ou uma forma de garantir que só é instanciado uma única vez.

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.

Exemplo:

public class SingleSpoon
{
private Soup soupLastUsedWith;

private static SingleSpoon theSpoon;
private static boolean theSpoonIsAvailable = true;

private SingleSpoon() {}

public static SingleSpoon getTheSpoon() {
if (theSpoonIsAvailable) {
if (theSpoon == null) {
theSpoon = new SingleSpoon();
}
theSpoonIsAvailable = false;
return theSpoon;
} else {
return null;
//spoon not available,
// could throw error or return null (as shown)
}
}

public String toString() {
return "Behold the glorious single spoon!";
}

public static void returnTheSpoon() {
theSpoon.cleanSpoon();
theSpoonIsAvailable = true;
}

public Soup getSoupLastUsedWith() {
return this.soupLastUsedWith;
}
public void setSoupLastUsedWith(Soup soup) {
this.soupLastUsedWith = soup;
}

public void cleanSpoon() {
this.setSoupLastUsedWith(null);
}
}

class TestSingleSpoon {

public static void main(String[] args) {
System.out.println("First person getting the spoon");
SingleSpoon spoonForFirstPerson =
SingleSpoon.getTheSpoon();
if (spoonForFirstPerson != null)
System.out.println(spoonForFirstPerson);
else
System.out.println("No spoon was available");

System.out.println("");

System.out.println("Second person getting a spoon");
SingleSpoon spoonForSecondPerson = SingleSpoon.getTheSpoon();
if (spoonForSecondPerson != null)
System.out.println(spoonForSecondPerson);
else
System.out.println("No spoon was available");

System.out.println("");

System.out.println("First person returning the spoon");
spoonForFirstPerson.returnTheSpoon();
spoonForFirstPerson = null;
System.out.println("The spoon was returned");

System.out.println("");

System.out.println("Second person getting a spoon");
spoonForSecondPerson = SingleSpoon.getTheSpoon();
if (spoonForSecondPerson != null)
System.out.println(spoonForSecondPerson);
else
System.out.println("No spoon was available");
}
}

Link Referência

Padrão ADAPTER

A função do Padrão ADAPTER é fazer com que a interface de uma classe possa ser "adaptada" à interface de uma outra para que essas possam trabalhar juntas. É a melhor forma de se ligar classes que tenham interfaces imcompatíveis. Podemos usar o Adapter caso seja necessário modificar a interface de uma classe em função de um novo requisito.

O padrão de projeto Adapter é necessário quando possuímos dois objetos que precisam se comunicar mas as suas interfaces são diferentes. O adaptador é responsável por "converter" uma interface em outra tornando possível a comunicação entre os objetos.

EXEMPLO:

public void TomadaTresPinos {
public void fornecerEnergia ();
}

public interface TomadaDoisPinos {
public void fornecerEnergia ();
}

public interface PlugueTresPinos {
public void conectar (TomadaTresPinos tomada) ;
}


public void PlugueDoisPinos {
public void conectar (TomadaDoisPinos) ;
}


public class TomadaEuropeia implements TomadaTresPinos {
public void fornecerEnergia() {

System.out.println("[TOMADA] Fornecendo energia para um plugue de três pinos!");
}

}

public class PlugueEuropeu implements PlugueTresPinos {
public void conectar(TomadaTresPinos tomada) {
System.out.println("[PLUGUE] Pegando energia elétrica de uma tomada de três pinos.");
tomada.fornecerEnergia();
}

}

public class PlugueComum implements PlugueDoisPinos {
public void conectar(TomadaDoisPinos tomada) {

System.out.println("[PLUGUE] Pegando energia elétrica de uma tomada de dois pinos.");
tomada.fornecerEnergia();
}

}

public class Adaptador implements TomadaTresPinos {

private TomadaDoisPinos tomada;

public Adaptador(TomadaDoisPinos tomada) {
this.tomada = tomada;
}

public void fornecerEnergia() {
tomada.fornecerEnergia();
}


}

public class Main {

public static void main(String[] args) {
TomadaDoisPinos tomada = new TomadaComum();
PlugueTresPinos plugue = new PlugueEuropeu();

Adaptador adapter = new Adaptador(tomada);
plugue.conectar(adapter);
}

}



Link Referência

...::: Padrões GOF :::...

História

O conceito de padrão de projeto foi criado na década de 70 pelo arquiteto Christopher Alexander . Em seus livros Notes on the Synthesis of Form, The Timeless Way of Building e A Pattern Language.

Além da definição das características de um padrão, Alexander definiu o formato que a descrição de um padrão deve ter. Ele estabeleceu que um padrão deve ser descrito em cinco partes:

Nome: uma descrição da solução, mais do que do problema ou do contexto.

Exemplo: uma ou mais figuras, diagramas ou descrições que ilustrem um protótipo de aplicação.

Contexto: a descrição das situações sob as quais o padrão se aplica.

Problema: uma descrição das forças e restrições envolvidos e como elas interagem.

Solução: relacionamentos estáticos e regras dinâmicas descrevendo
como construir artefatos de acordo com o padrão, freqüentemente citando
variações e formas de ajustar a solução segundo as circunstâncias.
Inclui referências a outras soluções e o relacionamento com outros
padrões de nível mais baixo ou mais alto.

O movimento ao redor de padrões de projeto ganhou popularidade com o livro Design Patterns: Elements of Reusable Object-Oriented Software , publicado em 1995 .
Os autores desse livro são Erich Gamma , Richard Helm , Ralph Johnson e John Vlissides , conhecidos como a "Gangue dos Quatro" (Gang of Four) ou simplesmente
"GoF". Posteriormente, vários outros livros do estilo foram publicados, como Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development.

Introdução:

Os padrões de projeto de software ou padrões de desenho de software , também muito conhecido pelo termo original em inglês : Design Patterns , descrevem soluções para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos.

Um padrão de projeto estabelece um nome e define o problema, a solução, quando aplicar esta solução e suas conseqüências.

Os padrões de projeto visam facilitar a reutilização de soluções de desenho - isto é, soluções na fase de projeto do software, sem considerar reutilização de código. Também acarretam um vocabulário comum de desenho, facilitando comunicação, documentação e aprendizado dos sistemas de software.


...::: Padrões GOF :::...

Os padrões "GoF" são organizados em famílias de padrões: de criação, estruturais e comportamentais. Os padrões de criação são relacionados à criação de objetos, os estruturais tratam das associações entre classes e objetos e os comportamentais das interações e divisões de responsabilidades entre as classes ou objetos.


Um padrão "GoF" também é classificado segundo o seu escopo; de classe ou de objeto. Nos padrões com escopo de classe os relacionamentos que definem este padrão são definidos através de herança e em tempo de compilação . Nos padrões com escopo de objeto o padrão é encontrado no relacionamento entre os objetos definidos em tempo de execução.