Eu gosto dessa tradução, porque traduz bem direitinho o que ele representa, é uma fachada para “esconder” chamadas de vários métodos de objetos diferentes atrás de um mesmo método. Pense assim:

Toda vez que eu aperto o botão de uma máquina de café e pedir um mocacchino, acontece a mesma coisa:

• Moe-se o café
• Pega-se um copo
• Esquenta-se a água
• Passa-se o café
• Coloca-se o café passado no copo
• Coloca-se o chocolate
• Coloca-se o leite
• Apita pra dizer que está pronto

Se olharmos isso com a visão de um pojetista, vemos que temos várias responsabilidades e que não podemos deixar tudo numa mesma classe, como por exemplo:

• Responsável por moer o café
• Responsável por colocar algo no copo
• Responsável por pegar 1 copo novo
• Responsabilidade de saber quanto de cada ingrediente por no copo
• Responsabilidade de apitar e escrever nos leds

Enfim, para que o código seja organizado, precisamos distribuir as responsabilidades de acordo com as necessidades e obrigações de cada classe. Porém, cada vez que o botão for pressionado, seria muito cruel ter que chamar várias classes e executar esses métodos que selecionam o copo, moem o grão, etc.

Para esses casos foi pensando o Facade Pattern, ou seja, a Fachada. Todo aquele algoritmo descrito na primeira lista acima, é encapsulado dentro de uma classe específica para a máquina de café, dentro do método pressionaBotao, por exemplo. Chamando o método, ele se encarrega de interagir com os objetos de seleção do copo, do cálculo da quantidade de ingredientes, etc.

Fiz um exemplo em perl, pensando num cinema. Acredito que fique fácil entender a partir dele. Seguem as classes utilizadas:

#!/usr/bin/perl -w
{
	# Classe representando o amplificador
	package Amplifier;
	# construtor
	sub new {
		my $class = shift;
		$class = ref($class) || $class;
		my $this = {};
		bless($this, $class);
		return $this;
	}
	# liga o amplificador
	sub on {
		my $this = shift;
		print "Turning the Amplifier [ON]\n";
	}
	# desliga o amplificador
	sub off {
		my $this = shift;
		print "Turning the Amplifier [OFF]\n";
	}
	# Muda o volume
	sub setVolume {
		my $this = shift;
		$volume = shift;
		print printf "Turning the Amplifiers volume to %d%%\n", $volume;
	}
	# coloca no mudo
	sub mute {
		my $this = shift;
		$this->setVolume(0);
	}
}
 
{
	# Classe representado o aparelho de DVD
	package Dvd;
	# construtor
	sub new {
		my $class = shift;
		$class = ref($class) || $class;
		my $this = {};
		$this->{state} = 'stop';
		$this->{movie} = undef;
		bless($this, $class);
		return $this;
	}
	# liga o dvd
	sub on {
		my $this = shift;
		print "Turning the DVD Player [ON]\n";
	}
	# desliga o dvd
	sub off {
		my $this = shift;
		print "Turning the DVD Player [OFF]\n";
	}
	# da play no filme
	sub play {
		my $this = shift;
		$movie = shift;
		if ($this->{state} eq 'play') {
			$this->{stop}();
			$this->{play}($movie);
		} else {
			$this->{movie} = $movie;
			$this->{state} = 'play';
			print printf "Playing the movie %s\n", $movie
		}
	}
	# da stop no filme
	sub stop {
		my $this = shift;
		if ($this->{state} eq 'play') {
			$this->{state} = 'stop';
			print printf "Stoping the movie %s\n", $this->{movie};
			$this->{movie} = undef;
		}
	}
	# ejeta a bandeja pra por no dvd
	sub eject {
		my $this = shift;
		if ($this->{state} eq 'play') {
			$this->{stop}();
		}
		print "Ejecting the DVD\n";
	}
}
{
	# classe representando o projetor
	package Projector;
	# construtor
	sub new {
		my $class = shift;
		$class = ref($class) || $class;
		my $this = {};
		bless($this, $class);
		return $this;
	}
	# ajusta o canal de vídeo
	sub videoChannel {
		my $this = shift;
		print "Setting Video Channel\n";
	}
	# liga o projetor
	sub on {
		my $this = shift;
		print "Turning the Project [ON]\n";
	}
	# desliga o projetor
	sub off {
		my $this = shift;
		print "Turning the Project [OFF]\n";
	}
}
{
	# Classe representando as luzes do cinema
	package Lights;
	# construtor
	sub new {
		my $class = shift;
		$class = ref($class) || $class;
		my $this = {};
		$this->{state} = 'off';
		bless($this, $class);
		return $this;
	}
	# liga as lâmpadas
	sub on {
		my $this = shift;
		if ($this->{state} eq 'off') {
			print "Turning the Lights [ON]\n";
			$this->{state} = 'on';
		}
	}
	# desliga as lâmpadas
	sub off {
		my $this = shift;
		if ($this->{state} eq 'on') {
			$this->{state} = 'off';
			print "Turning the Lights [OFF]\n";
		}
	}
}
{
	# classe representando uma máquina de pipoca
	package PopcornMachine;
	# construtor
	sub new {
		my $this = {};
		my $class = shift;
		$class = ref($class) || $class;
		$this->{state} = 'off';
		bless($this, $class);
		return $this;
	}
	# liga a máquina
	sub on {
		my $this = shift;
		if ($this->{state} eq 'off') {
			$this->{state} = 'on';
			print "Turning the Popcorn Machine [ON]\n";
		}
	}
	# estoura as pipocas
	sub pop {
		my $this = shift;
		if ($this->{state} eq 'on') {
			print "Poping the corns ;P\n";
		}
	}
	# desliga a máquina
	sub off {
		my $this = shift;
		if ($this->{state} eq 'on') {
			$this->{state} = 'off';
			print "Turning the Popcorn Machine [OFF]\n";
		}
	}
}

A orientação a objetos no perl é meio sinistra. Existem diversas formas de se programar orientado a objetos no perl, eu escolhi esta pois parece mais simples e fácil. Bom, essas são as classes utilizadas:

• Amplifier
• DVD
• Projector
• Lights
• PopcornMachine

Bom, cada vez que um filme inicia ou termina no cinema, várias operações são repetidas sempre. Alguém já viu cinema com as luzes acesas? Bem, sempre se desliga as luzes. Então observe a classe abaixo que representa o Facade.

{
	# classe representando o cinema
	package CineFacade;
	# construtor
	sub new {
		my $this = {};
		my $class = shift;
		$class = ref($class) || $class;
		$this->{amplifier} = shift || undef;
		$this->{dvd} = shift || undef;
		$this->{projector} = shift || undef;
		$this->{lights} = shift || undef;
		$this->{popcornMachine} = shift || undef;
		bless ($this, $class);
		return $this;
	}
	# começa a ver o filme
	sub watchMovie {
		my $this = shift;
		$movie = shift;
		# Popcorn machine
		$this->{popcornMachine}->on();
		$this->{popcornMachine}->pop();
		# Home lights
		$this->{lights}->off();
		# Projector
		$this->{projector}->on();
		$this->{projector}->videoChannel();
		# Amplifier
		$this->{amplifier}->on();
		$this->{amplifier}->setVolume(100);
		# DVD
		$this->{dvd}->on();
		$this->{dvd}->play($movie);
	}
	# termina de ver o filme
	sub endMovie {
		my $this = shift;
 
		$this->{popcornMachine}->off();
		$this->{lights}->on();
		$this->{projector}->off();
		$this->{amplifier}->off();
		$this->{dvd}->stop();
		$this->{dvd}->eject();
		$this->{dvd}->off();
	}
}

Observem o método watchMovie e endMovie. Eles chamam operações comum a todas as seções do cinema.
Aqui vai o exemplo de uso do facade no meio da aplicação:

{
	# Exemplo de uso
	$cine = CineFacade->new(
			Amplifier->new(),
			Dvd->new(),
			Projector->new(),
			Lights->new(),
			PopcornMachine->new()
			);
 
	print "Movie Session started: \n\n";
	$cine->watchMovie('Titanic');
 
	print "Movie Session ended: \n\n";
	$cine->endMovie();
}

O output é mais ou menos assim:

Movie Session started: 
 
Turning the Popcorn Machine [ON]
Poping the corns ;P
Turning the Project [ON]
Setting Video Channel
Turning the Amplifier [ON]
Turning the Amplifiers volume to 100%
Turning the DVD Player [ON]
Playing the movie Titanic
 
Movie Session ended: 
 
Turning the Popcorn Machine [OFF]
Turning the Lights [ON]
Turning the Project [OFF]
Turning the Amplifier [OFF]
Stoping the movie Titanic
Ejecting the DVD

O que é Adapter Pattern?

Bom, imaginemos aqueles cartões de memória de máquina fotográfica. Existem de várias tamanhos, micro, pequenos, grandes, gigantes. Seria realmente uma merda se uma máquina fotográfica suportasse somente 1 tamanho, por isso foi inventada aqueles… adivinhem… adaptadores que permitem que micros e pequenos caibam em grande, por exemplo. Todos tem a mesma finalidade, porém, têm tamanhos diferentes.Para isso serve o Adapter Pattern, para resolver justamente esse tipo de problema.

Quando se fala em abstração, geralmente se fala em Adapter Pattern, justamente por isso, porque ele te permite, com um mesmo objeto, fazer ações diferentes com uma finalidade em comum.

Para entendermos melhor, pensemos no caso de abstração de banco de dados. A sintaxe de cada um é diferente, porém têm as mesmas claúsulas. Alguns permitem transações, outros não. Pois esta é uma situação perfeita para o Adapter Pattern. Mas seria muito complexo explicar utilizando ela como exemplo, logo, fiz um exemplo em python que vai ajudar.

class ShapeAbstract(object):
 
	def countCorner(self):
		return self.corners
 
	def __str__(self):
		return self.name
 
	def area(self): abstract
 
class SquareShape(ShapeAbstract):
	def __init__(self, x, y=None):
		self.corners = 4
		self.name = 'Square'
		if (x is not None):
			self.l = x
 
	def area(self):
		return self.l*self.l
 
class TriangleShape(ShapeAbstract):
	def __init__(self, x, y):
		self.corners = 3
		self.name = 'Triangle'
		self.x = x
		self.y = y
 
	def area(self):
		return ((self.x*self.y)/2)

Bom, Tudo começa na nossa classe abstrata ShapeAbstract. Ela é a classe que vai servir de base para todos as formas que vamos calcular a área. Temos a classe SquareShape que representa um quadrado (jura? :/). O construtor da classe, __init__, recebe 2 valores: altura e a largura. Visto que é um quadrado, todos os lados são iguais, não é necessário passar a altura, ficamos somente com a largura. O que difere do triângulo, cujas medidas são base e altura. A nomenclatura não importa, no caso, vamos utilizar no máximo 2 medidas.

Nosso adapter é simplório, caso houvesse a necessidade de calcular a área de um trapésio, seria necessário mais um parâmetro, afinal, a fórmula é: ((base maior + base menor) / 2 * altura). Isso é facilmente implantado utilizando apenas mais um parâmetro no __init__, porque o que realmente queremos é fazer com que o método area() nos retorne a área.

import Shapes
 
class Shape(object):
 
	def setAdapter(self, Adapter):
		self.Adapter = Adapter
 
	def countCorner(self):
		return self.Adapter.countCorner()
 
	def area(self):
		return self.Adapter.area()
 
	def __str__(self):
		return self.Adapter.__str__();
 
	def newShape(ShapeAdapter):
		shape = Shape()
		shape.setAdapter(ShapeAdapter)
		return shape
 
	newShape = staticmethod(newShape)
 
if __name__ == '__main__':
	shape = Shape.newShape(Shapes.SquareShape(5))
	print shape
	print shape.countCorner()
	print shape.area()
        #Imprime:
        #Square
        #4
        #25
 
	shape = Shape.newShape(Shapes.TriangleShape(5,6))
	print shape
	print shape.countCorner()
	print shape.area()
        #Imprime:
        #Triangle
        #3
        #15

Nesta “aplicação principal” vemos a real classe adaptativa: Shape. Ela recebe a instância da classe e executa os métodos dela. Parece bobo ter uma classe que executa o método de outra classe, mas é fundamental para o reuso e a famosa abstração.

Vejam que elas se comportam diferentes. Claro, são formas diferentes! Áreas diferentes! Número de cantos diferentes! E nomes direfentes!

Agora fica fácil ver esse exemplo abstraindo, por exemplo, um banco de dados? Pense que a classe Shape seja Database, TriangleShape seja MySQLDatabase e SquareShape seja MSSQLDatabase, o método area() seja o método setLimit().

shape = Database(MySQLDatabase())
print shape.setLimit(5);
#Imprimi: LIMIT 5
shape = Database(MSSQLDatabase())
print shape.setLimit(5);
#Imprimi: TOP 5

Usando Adapter para 3rd part

Uma das minhas sugestões de uso do Adapter Pattern é com integração de código de terceiros. Vamos supor que você tenha 3 bibliotecas que geram gráficos: X, Y e Z. A bilioteca X é muito boa, mas não tem gráficos em pizza, que na Y tem. Mas a Z, por sua vez, tem gráficos em pizza em 3d. Vamos analizar a situação:

• A responsabilidade é a mesma: gerar um gráfico.
• Independente do tipo de gráfico (com barras, pizza, etc), todas elas vão receber os mesmos tipos de dados.
• Cada biblioteca tem seus próprios métodos, com nomes diferentes, mas para as mesma finalidade

Não parece um lugar perfeito para se utilizar o Adapter Pattern? Ora, vamos fazer um pequeno esboço:

graph = GraphAdapter()
graph.setData(([20,30,10],[15,25,35]))
graph.desenhaGrafico(GRAFICOS.BARRA)
graph.desenhaGrafico(GRAFICOS.PIZZA)
graph.desenhaGrafico(GRAFICOS.PIZZA3D)

Observem que não utilizei a instância de uma classe como adapter, utilizei constantes que vão determinar, na hora de desenhar o gráfico, o tipo dele. Se for BARRA, faz justamente como a biblioteca X exige, usando a API dela. O mesmo para PIZZA (Y) e PIZZA3D (Z). Pronto! Você, utilizando patterns, terá seu próprio modo de gerar gráficos, mesmo que com bibliotecas diferentes! Comentem e até a próxima!

Decorator Pattern

É um pattern desenvolvido para modificar um determinado objeto (seja modificar alguma coisa já existente ou delegar uma nova responsabilidade) sem a necessidade de extendê-lo. O que é muito bom, assim, o reaproveitamento de código é maior ainda! Enfim, vou tentar dar uma explicada no pattern:

Diagrama de Classes do Decorator Pattern

Abaixo segue o código usado:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91

class Message {
 
	protected $msg;
 
	public function __construct($msg) {
		$this->setMsg($msg);
	}
 
	public function getMsg() {
		return $this->msg;
	}
 
	public function setMsg($msg) {
		$this->msg = $msg;
	}
 
	public function __toString() {
		return $this->getMsg();
	}
 
}
 
class Success_Message extends Message {
	public function __construct($msg) {
		parent::__construct($msg);
		$msg = new DivClass_Decorator(
			new Li_Decorator(
				$this
			)
			,'success-msg');
		$this->setMsg((String)$msg);
	}
}
 
class Error_Message extends Message {
 
	public function __construct($msg) {
		parent::__construct($msg);
		$newmsg = new DivClass_Decorator(
			new Li_Decorator(
				$this
			)
			,'error-msg');
		$this->setMsg((String)$newmsg);
	}
 
}
 
interface Msg_Decorator_Interface {
	function render(Message $message);
}
 
abstract class Msg_Decorator_Abstract extends Message {
 
	public function __construct(Message $msg) {
		$this->render($msg);
	}
 
}
 
class Li_Decorator extends Msg_Decorator_Abstract implements Msg_Decorator_Interface {
 
	public function render(Message $message) {
		$msg = $message->getMsg();
		$this->setMsg('<ul><li>'. $msg .'</li></ul>');
	}
 
}
 
class Div_Decorator extends Msg_Decorator_Abstract implements Msg_Decorator_Interface {
 
	public function render(Message $message) {
		$this->setMsg('<div>'. $message->getMsg() .'</div>');
	}
 
}
 
class DivClass_Decorator extends Msg_Decorator_Abstract implements Msg_Decorator_Interface {
 
	private $class;
 
	public function __construct(Message $msg, $class = null) {
		$this->class = $class;
		parent::__construct($msg);
	}
 
	public function render(Message $message) {
		$this->setMsg('<div class="'.(null === $this->class?'default-class':$this->class).'">'.$message->getMsg().'</div>');
	}
 
}

OK! Com o código em mãos, vamos pensar um pouquinho. Tenho uma cacetada de classes, todas fazendo praticamente a mesma coisa. E agora? Calma, Juvenal. Vamos analizar:

1. Temos a classe Mensagem. Sabemos que ele representa uma mensagem. Métodos básicos para manipularmos a mensagem e um __toString() que irá retornar o valor em string pra classe quando for feito o cast.
2. Classe Msg_Decorator_Abstract que extende da classe Mensagem. Todos os nossos decoradores, por assim dizer, irão ser filhos desta classe. O exemplo é tão simples que a classe abstrata nem tem métodos abstratos. Mas a idéia é que tenha, caso necessário.
3. Msg_Decorator_Interface, essa interface obriga os programadores que quiserem criar decorators a escrever o método render(). Que é chamado pela nossa classe Abstract no construtor.
4. Li_Decorator, Div_Decorator e DivClass_Decorator são exemplos de decorators.

Vamos ver o negócio funcionando? Vamos escrever o seguinte código:

1
2
3
4
5

   	print new Div_Decorator(
			new Li_Decorator(
				new Message("Mensagem de teste!")
			)
		);

Irá imprimir

1
2
3
4
5

<div>
<ul>
	<li>Mensagem de teste!</li>
</ul>
</div>

Viram? Simples e prático! Claro que o exemplo é bem simples e talvez nem seja tão útil. Mas é só pensar um pouquinho mais que logo surgem exemplos onde se usar o Decorator.

Entender agora fica mais fácil. Apenas comece olhando do meio para a esquerda. Primeiro nós instanciamos a classe Message com o mensagem “Mensagem de teste!”. O método getMsg() retornará exatamente isso: “Mensagem de teste!”. Porém, no momento em que é instanciado o Li_Decorator, ele vai mudar a mensagem usando o método render(), que deve ser implementado na Msg_Decorator_Interface e chamado na Msg_Decorator_Abstract pelo construtor. E assim acontece com o Div_Decorator.

Notem que eu decidi mudar o valor da mensagem usando o setMsg. Eu já li em alguns lugares onde fica armazenada a instância da classe anterior e então o método getMsg seria chamado em forma de cascata, fazendo com que a mensagem original nunca fosse alterada de verdade, e no fim ela é, igual a um método recursivo, retornada decorada e maquiada.

Reutilizando o código

Bom, como eu havia dito no começo, o Observer Pattern nos possibilita o reuso. O exemplo são aquelas duas classes das quais eu não cheguei a falar: Error_Message e Success_Message.

Observem que são simples e, utilizando os Decorators já existentes, mostram uma mensagem personalizada de Erro e de Sucesso! Para utilizá-las, basta usar:

1
2

print new Error_Message("Erro! Você fez algo errado!");
print new Success_Message("Sucesso! Parabéns!");

O que imprimirá:

1
2
3
4
5
6
7
8
9
10

<div class="error-msg">
<ul>
	<li>Error!</li>
</ul>
</div>
<div class="success-msg">
<ul>
	<li>Sucesso! Parabéns!</li>
</ul>
</div>

Prós

• Adiciona flexibilidade ao código.
• Facilmente reutilizada.
• Ótimo para sistemas que possibilitam o uso de plugins.

Contras

• Gera um grande número de arquivos (se for pensar que cada arquivo é uma classe ou vice-versa).
• Dependendo da quantidade de classes aloca muita memória.
• Ruim para sistemas mais fechados e bitolados ou muito padronizados.

Acho que é isto pessoal. O que acharam? Não é um bixo de sete cabeças, né?