Você já esteve em uma equipe em que precisou começar um projeto do zero? Este é frequentemente o caso em muitas start-ups e outras pequenas empresas.

Existem tantas linguagens de programação, arquiteturas e outras preocupações diferentes que pode ser difícil descobrir por onde começar. É aí que entram os padrões de projeto.

Um padrão de projeto (do inglês, design pattern) é como um modelo para o seu projeto. Ele usa certas convenções e você pode esperar um tipo específico de comportamento dele. Esses padrões foram compostos de experiências de muitos desenvolvedores. Então, eles são realmente como diferentes conjuntos de melhores práticas.

Você e sua equipe decidem qual conjunto de melhores práticas é o mais útil para o seu projeto. Com base no padrão de projeto escolhido, todos vocês começarão a ter expectativas sobre o que o código deve fazer e sobre qual vocabulário usarão.

Os padrões de projeto de programação podem ser usados em todas as linguagens de programação e para se adequar a qualquer projeto, pois eles fornecem apenas um esboço geral de uma solução.

Existem 23 padrões oficiais no livro Design Patterns - Elements of Reusable Object-Oriented Software, que é considerado um dos livros mais influentes de teoria sobre a programação orientada a objetos e sobre desenvolvimento de software.

Neste artigo, abordarei quatro desses padrões de projeto para dar uma ideia do que são alguns dos padrões e quando você os usaria.

O padrão de projeto Singleton

O padrão singleton  permite que uma classe ou objeto tenha apenas uma instância e utilize uma variável global para armazenar essa instância. Você pode usar o carregamento lento (do inglês, lazy loading) para garantir que haja apenas uma instância da classe, pois ela só será criada quando você precisar.

Isso impede que múltiplas instâncias estejam ativas ao mesmo tempo, o que poderia causar bugs estranhos. Na maioria das vezes, isso é implementado no construtor. O objetivo do padrão singleton é, geralmente, regular o estado global de uma aplicação.

Um exemplo de singleton que você provavelmente usa o tempo todo é o seu log. Se você trabalha com alguns dos frameworks de front-end, como React ou Angular, sabe tudo sobre como pode ser difícil lidar com logs vindos de múltiplos componentes. Este é um ótimo exemplo de singletons em ação, pois você nunca quer mais de uma instância de um objeto de log, especialmente se estiver usando algum tipo de ferramenta de rastreamento de erros.

class FoodLogger {
  constructor() {
    this.foodLog = []
  }
    
  log(order) {
    this.foodLog.push(order.foodItem)
    // faça um código elegante para enviar esse log para algum lugar
  }
}

// este é o singleton
class FoodLoggerSingleton {
  constructor() {
    if (!FoodLoggerSingleton.instance) {
      FoodLoggerSingleton.instance = new FoodLogger()
    }
  }
  
  getFoodLoggerInstance() {
    return FoodLoggerSingleton.instance
  }
}

module.exports = FoodLoggerSingleton

Agora, você não precisa se preocupar em perder logs de múltiplas instâncias, pois você só tem uma em seu projeto. Então, quando você quiser registrar o alimento que foi encomendado, pode usar a mesma instância de FoodLogger em múltiplos arquivos ou componentes.

const FoodLogger = require('./FoodLogger')

const foodLogger = new FoodLogger().getFoodLoggerInstance()

class Customer {
  constructor(order) {
    this.price = order.price
    this.food = order.foodItem
    foodLogger.log(order)
  }
  
  // outras coisas legais acontecendo para o cliente
}

module.exports = Customer

const FoodLogger = require('./FoodLogger')

const foodLogger = new FoodLogger().getFoodLoggerInstance()

class Restaurant {
  constructor(inventory) {
    this.quantity = inventory.count
    this.food = inventory.foodItem
    foodLogger.log(inventory)
  }
  
// outras coisas legais acontecendo no restaurante

module.exports = Restaurant

Com esse padrão singleton instalado, você não precisa se preocupar apenas em obter os logs do arquivo principal da aplicação. Você pode obtê-los de qualquer lugar em sua base de código e todos eles vão exatamente para a mesma instância do logger, o que significa que nenhum de seus logs deve ser perdido devido a novas instâncias.

O padrão de projeto Strategy

O padrão Strategy é como uma versão avançada de uma instrução "if else". É basicamente onde você cria uma interface para um método que você tem em sua classe base. Essa interface é usada para encontrar a implementação correta desse método que deve ser usado em uma classe derivada. A implementação, nesse caso, será decidida em tempo de execução com base no client.

O padrão Strategy é incrivelmente útil em situações em que você tem métodos obrigatórios e opcionais para uma classe. Algumas instâncias dessa classe não precisarão dos métodos opcionais e isso causa um problema para soluções de herança. Você poderia usar interfaces para os métodos opcionais, mas então teria que escrever a implementação toda vez que usasse essa classe, já que não haveria uma implementação padrão.

É aí que o padrão Strategy nos salva. Em vez do client procurar por uma implementação, ele delega para uma interface de Strategy e esta encontra a implementação correta. Um uso comum para isso é com sistemas de processamento de pagamentos.

Você poderia ter um carrinho de compras que só permite que os clientes finalizem a compra com cartões de crédito, mas perderia clientes que querem usar outros métodos de pagamento.

O padrão de projeto strategy nos permite desacoplar os métodos de pagamento do processo de finalização da compra, o que significa que podemos adicionar ou atualizar estratégias sem alterar nenhum código no carrinho de compras ou no processo de finalização da compra.

Aqui está um exemplo de uma implementação do padrão Strategy usando o exemplo de método de pagamento.

class PaymentMethodStrategy {

  const customerInfoType = {
    country: string
    emailAddress: string
    name: string
    accountNumber?: number
    address?: string
    cardNumber?: number
    city?: string
    routingNumber?: number
    state?: string
  }
  
  static BankAccount(customerInfo: customerInfoType) {
    const { name, accountNumber, routingNumber } = customerInfo
    // faz coisas para receber o pagamento
  }
  
  static BitCoin(customerInfo: customerInfoType) {
    const { emailAddress, accountNumber } = customerInfo
    // faz coisas para receber o pagamento
  }
  
  static CreditCard(customerInfo: customerInfoType) {
    const { name, cardNumber, emailAddress } = customerInfo
    // faz coisas para receber o pagamento
  }
  
  static MailIn(customerInfo: customerInfoType) {
    const { name, address, city, state, country } = customerInfo
    // faz coisas para receber o pagamento
  }
  
  static PayPal(customerInfo: customerInfoType) {
    const { emailAddress } = customerInfo
    // faz coisas para receber o pagamento
  }
}

Para implementar nosso método de pagamento de Strategy, criamos uma única classe com vários métodos estáticos. Cada método usa o mesmo parâmetro, customerInfo, e esse parâmetro tem um tipo definido de customerInfoType (viram só, vocês, desenvolvedores que usam TypeScript?). Observe que cada método tem sua própria implementação e usa valores diferentes de customerInfo.

Com o padrão Strategy, você também pode alterar dinamicamente a estratégia que está sendo usada no tempo de execução. Isso significa que você poderá alterar a estratégia ou implementação do método, sendo usado com base na entrada do usuário ou no ambiente em que a aplicação está sendo executada.

Você também pode definir uma implementação padrão em um arquivo config.json simples, como este:

{
  "paymentMethod": {
    "strategy": "PayPal"
  }
}

Sempre que um cliente começar a fazer o check-out em seu site, o método de pagamento padrão que ele encontra é a implementação do PayPal que vem do config.json. Isso pode ser facilmente atualizado se o cliente selecionar um método de pagamento diferente.

Agora, vamos criar um arquivo para o nosso processo de check-out.

const PaymentMethodStrategy = require('./PaymentMethodStrategy')
const config = require('./config')

class Checkout {
  constructor(strategy='CreditCard') {
    this.strategy = PaymentMethodStrategy[strategy]
  }
  
  // faça algum código sofisticado aqui e obtenha a entrada do usuário e o método de pagamento
  
  changeStrategy(newStrategy) {
    this.strategy = PaymentMethodStrategy[newStrategy]
  }
  
  const userInput = {
    name: 'Malcolm',
    cardNumber: 3910000034581941,
    emailAddress: 'mac@gmailer.com',
    country: 'US'
  }
  
  const selectedStrategy = 'Bitcoin'
  
  changeStrategy(selectedStrategy)
  
  postPayment(userInput) {
    this.strategy(userInput)
  }
}

module.exports = new Checkout(config.paymentMethod.strategy)

Essa classe Checkout é onde o padrão Strategy pode ser exibido. Importamos alguns arquivos para termos as estratégias de método de pagamento disponíveis e o padrão Strategy do config.

Em seguida, criamos a classe com o construtor e um valor de fallback para o padrão Strategy caso não haja um definido na configuração. Em seguida, atribuímos o valor de Strategy a uma variável de estado local.

Um método importante que precisamos implementar em nossa classe Checkout é a capacidade de alterar a estratégia de pagamento. Um cliente pode alterar o método de pagamento que deseja usar e você precisa ser capaz de lidar com isso. É para isso que serve o método changeStrategy.

Depois de fazer uma codificação sofisticada e obter todas as entradas de um cliente, você pode atualizar a estratégia de pagamento imediatamente com base na entrada e definir dinamicamente a variável strategy antes que o pagamento seja enviado para processamento.

Em algum momento, você pode precisar adicionar mais métodos de pagamento ao seu carrinho de compras e tudo o que você precisa fazer é adicioná-lo à classe PaymentMethodStrategy. Ele estará disponível instantaneamente em qualquer lugar em que a classe for usada.

O padrão de projeto Strategy é poderoso quando você está lidando com métodos que possuem múltiplas implementações. Pode parecer que você está usando uma interface, mas não precisa escrever uma implementação para o método toda vez que o chama em uma classe diferente. Ele oferece mais flexibilidade do que as interfaces.

O padrão de projeto Observer

Se você já usou o padrão MVC, você já usou o padrão de projeto observer. A parte do Modelo é semelhante ao "observado" e a parte da View é como um observador (do inglês, observer) do modelo. Seu modelo mantém todos os dados e o estado desses dados. Então, você tem os observers, como diferentes componentes, que vão pegar esses dados do observado quando os dados forem atualizados.

O objetivo do padrão de projeto Observer é criar essa relação de um para muitos entre o observado e todos os observers esperando por dados para que possam ser atualizados. Então, sempre que o estado do observado mudar, todos os observers serão notificados e atualizados instantaneamente.

Alguns exemplos de quando você usaria esse padrão incluem: envio de notificações de usuário, atualização, filtros e tratamento de assinantes.

Digamos que você tenha uma aplicação de página única com três listas suspensas de recursos, que dependem da seleção de uma categoria em uma lista suspensa de nível superior. Isso é comum em muitos sites de compras, como o Home Depot. Você tem vários filtros na página que dependem do valor de um filtro de nível superior.

O código para o menu suspenso de nível superior pode ser mais ou menos assim:

class CategoryDropdown {
  constructor() {
    this.categories = ['appliances', 'doors', 'tools']
    this.subscriber = []
  }
  
  // finja que há algum código sofisticado aqui
  
  subscribe(observer) {
    this.subscriber.push(observer)
  }
  
  onChange(selectedCategory) {
    this.subscriber.forEach(observer => observer.update(selectedCategory))
  }
}

Este arquivo CategoryDropdown é uma classe simples com um construtor que inicializa as opções de categoria disponíveis no menu suspenso. Este é o arquivo que você usaria para recuperar uma lista do back-end ou qualquer tipo de classificação que deseja fazer antes que o usuário veja as opções.

O método subscribe é como cada filtro criado com essa classe receberá atualizações sobre o estado do Observer.

O método onChange é como enviamos uma notificação a todos os assinantes de que uma mudança de estado ocorreu no Observer que eles estão olhando. Apenas percorremos todos os assinantes e chamamos seu método de atualização com a categoria selectedCategory.

O código para os outros filtros pode parecer algo assim:

class FilterDropdown {
  constructor(filterType) {
    this.filterType = filterType
    this.items = []
  }
  
  // mais código elegante aqui; talvez faça a chamada da API para obter a lista de itens baseada no filterType
  
  update(category) {
    fetch('https://example.com')
      .then(res => this.items(res))
  }
}

Esse arquivo FilterDropdown é outra classe simples que representa todos os possíveis menus suspensos que podemos usar em uma página. Quando uma nova instância dessa classe é criada, ela precisa receber um filterType. Isso pode ser usado para fazer chamadas de API específicas para obter a lista de itens.

O método update é uma implementação do que você pode fazer com a nova categoria depois que ela foi enviada pelo Observer.

Agora, veremos o que significa usar esses arquivos com o padrão Observer:

const CategoryDropdown = require('./CategoryDropdown')
const FilterDropdown = require('./FilterDropdown')

const categoryDropdown = new CategoryDropdown() 

const colorsDropdown = new FilterDropdown('colors')
const priceDropdown = new FilterDropdown('price')
const brandDropdown = new FilterDropdown('brand')

categoryDropdown.subscribe(colorsDropdown)
categoryDropdown.subscribe(priceDropdown)
categoryDropdown.subscribe(brandDropdown)

O que este arquivo nos mostra é que temos 3 menus suspensos que são assinantes da categoria drop-down observável. Em seguida, assinamos cada um desses drop-downs para o Observer. Sempre que a categoria do Observer for atualizada, ele enviará o valor para cada assinante, o que atualizará as listas de drop-down individuais instantaneamente.

O padrão de projeto Decorator

Usar o padrão de projeto Decorator é bastante simples. Você pode ter uma classe base com métodos e propriedades que estão presentes quando você cria um objeto com a classe. Agora, digamos que você tenha algumas instâncias da classe que precisam de métodos ou propriedades que não vieram da classe base.

Você pode adicionar esses métodos e propriedades extras à classe base, mas isso poderia estragar suas outras instâncias. Você poderia até criar subclasses para conter métodos e propriedades específicos que você precisa e que não pode colocar na sua classe base.

Qualquer uma dessas abordagens resolverá o seu problema, mas são desajeitadas e ineficientes. É aí que entra o padrão Decorator. Em vez de deixar o seu código base feio só para adicionar algumas coisas a uma instância de objeto, você pode colar essas coisas específicas diretamente na instância.

Então, se você precisar adicionar uma nova propriedade que contenha o preço de um objeto, você pode usar o padrão decorator para adicioná-lo diretamente a essa instância de objeto particular e isso não afetará qualquer outra instância desse objeto de classe.

Você já comprou comida on-line? Então, provavelmente, já encontrou o padrão Decorator. Se você estiver pegando um sanduíche e quiser adicionar coberturas especiais, o site não está adicionando essas coberturas a todas as instâncias de sanduíche que os usuários estão tentando pedir.

Aqui está um exemplo de uma classe de cliente:

class Customer {
  constructor(balance=20) {
    this.balance = balance
    this.foodItems = []
  }
  
  buy(food) {
    if (food.price) < this.balance {
      console.log('you should get it')
      this.balance -= food.price
      this.foodItems.push(food)
    }
    else {
      console.log('maybe you should get something else')
    }
  }
}

module.exports = Customer

Aqui está um exemplo de uma classe de sanduíche:

class Sandwich {
  constructor(type, price) {
    this.type = type
    this.price = price
  }
  
  order() {
    console.log(`Você pediu um sanduíche de ${this.type} no valor de $ ${this.price}.`)
  }
}

class DeluxeSandwich {
  constructor(baseSandwich) {
    this.type = `${baseSandwich.type} deluxe`
    this.price = baseSandwich.price + 1.75
  }
}

class ExquisiteSandwich {
  constructor(baseSandwich) {
    this.type = `${baseSandwich.type} delicioso`
    this.price = baseSandwich.price + 10.75
  }
  
  order() {
    console.log(`Você pediu um sanduíche ${this.type}. Ele tem o que você precisa para ficar feliz por dias.`)
  }
}

module.exports = { Sandwich, DeluxeSandwich, ExquisiteSandwich }

A classe de sanduíche é onde o padrão Decorator é usado. Temos uma classe base Sandwich que estabelece as regras para o que acontece quando um sanduíche regular é encomendado. Os clientes podem querer atualizar os sanduíches e isso significa apenas uma mudança de ingredientes e preço.

Você só queria adicionar a funcionalidade de aumentar o preço e atualizar o tipo de sanduíche para o DeluxeSandwich sem mudar como é encomendado. Embora possa ser necessário um método de pedido diferente para o ExquisiteSandwich devido à mudança drástica na qualidade dos ingredientes.

O padrão decorator permite que você altere dinamicamente a classe base sem afetá-la ou a qualquer outra classe. Você não precisa se preocupar em implementar funções que não sabe, como com interfaces, e não precisa incluir propriedades que não usará em todas as classes.

Agora, vamos passar por um exemplo onde essa classe é instanciada como se um cliente estivesse fazendo um pedido de sanduíche.

const { Sandwich, DeluxeSandwich, ExquisiteSandwich } = require('./Sandwich')
const Customer = require('./Customer')

const cust1 = new Customer(57)

const turkeySandwich = new Sandwich('Peru', 6.49)
const bltSandwich = new Sandwich('Bacon, alface e tomate', 7.55)

const deluxeBltSandwich = new DeluxeSandwich(bltSandwich)
const exquisiteTurkeySandwich = new ExquisiteSandwich(turkeySandwich)

cust1.buy(turkeySandwich)
cust1.buy(bltSandwich)

Considerações finais

Eu costumava achar que os padrões de projeto eram essas orientações de desenvolvimento de software loucas e distantes. Mais tarde, descobri que os utilizo o tempo todo!

Alguns dos padrões que abordei são usados em tantas aplicações que fariam sua cabeça girar. Eles são apenas teoria no fim das contas. Cabe a nós, desenvolvedores, usar essa teoria de maneiras que tornem nossas aplicações fáceis de implementar e de manter.

Você já usou algum dos outros padrões de projeto em seus projetos? A maioria dos lugares geralmente escolhe um padrão de projeto e adere a ele. Então, gostaria de ouvir de vocês sobre os padrões que vocês usam.

Obrigado pela leitura.

Siga a autora no Twitter, onde ela publica sobre coisas úteis e/ou divertidas.

O que é um padrão de projeto?

Padrões de projeto são soluções em nível de design para problemas recorrentes que os engenheiros de software encontram com frequência. Não são código - repito, ❌CÓDIGO. Eles são como uma descrição de como lidar com esses problemas e projetar uma solução.

Usar esses padrões é considerado uma boa prática, já que o projeto da solução foi testado muitas vezes e com sucesso, resultando em maior legibilidade do código final. Padrões de projetos são, com frequência, criados para linguagens de POO (Programação Orientada a Objetos), como o Java, e usadas por elas. Será em Java que escreveremos os exemplos que daremos daqui até o final do texto.

Tipos de padrões de projetos

Existem cerca de 26 padrões descobertos atualmente (não acho que tratarei de todos eles).

Esses 26 podem ser classificados em 3 tipos:

1. Criacionais: esses padrões foram criados para a instanciação de classes. Eles podem tanto ser padrões de criação de classes como de criação de objetos.

2. Estruturais: esses padrões foram criados levando em conta a estrutura de uma classe e sua composição. O objetivo principal da maioria desses padrões é aumentar a funcionalidade das classes envolvidas, sem alterar muito de sua composição.

3. Comportamentais: esses padrões foram criados levando em conta a forma como uma classe se comunica com as outras.

Neste artigo, examinarei um padrão de projeto básico para cada tipo classificado.

Tipo 1: Criacional – o padrão de projeto Singleton

O padrão de projeto Singleton é um padrão criacional, cujo objetivo é criar apenas uma instância de uma classe e fornecer apenas um ponto global de acesso àquele objeto. Um exemplo comumente usado dessa classe em Java é o calendário, onde você não pode fazer uma instância daquela classe. Ele também usa seu próprio método getInstance()para obter o objeto a ser usado.

Uma classe usando o padrão de projeto Singleton incluirá,

1. Uma variável estática privada, que contém a única instância da classe.
2. Um construtor privado, de modo a não ser possível instanciá-la de qualquer outro lugar.
3. Um método estático público, para retornar a instância única da classe.

Há muitas implementações diferentes do padrão Singleton. Hoje, examinarei as implementações:

1. Instanciação ávida

2. Instanciação preguiçosa

3. Instanciação thread-safe

A ávida (Eager)

public class EagerSingleton {
	// cria uma instância da classe.
	private static EagerSingleton instance = new EagerSingleton();

	// construtor privado, para que ela não possa ser instanciada fora da classe.
	private EagerSingleton() {  }

	// obtém a única instância criada do objeto.
	public static EagerSingleton getInstance() {
		return instance;
	}
}

Esse tipo de instanciação acontece durante o carregamento da classe, já que a instância da variável acontece fora de qualquer método. Isso impõe uma desvantagem substancial se essa classe não for usada pela aplicação do client. O plano de contingência, se essa classe não for usada, é a instanciação preguiçosa.

A preguiçosa (Lazy)

Não há muita diferença com relação à implementação acima. As principais diferenças estão na variável estática, que inicialmente é declarada como null (nula), e no fato de que ela é instanciada apenas dentro do método getInstance() se e somente se a variável de instância permanecer null (nula) no momento da verificação.

public class LazySingleton {
	// inicializa a instância como null.
	private static LazySingleton instance = null;

	// construtor privado, para que ela não possa ser instanciada fora da classe.
	private LazySingleton() {  }

	// verifica se a instância é null. Se estiver, o objeto é criado.
	public static LazySingleton getInstance() {
		if (instance == null) {
			instance = new LazySingleton();
		}
		return instance;
	}
}

Isso conserta um problema, mas ainda existe outro. E se dois clients diferentes acessarem a classe Singleton ao mesmo tempo? Bem, elas verificarão se a instância está null ao mesmo tempo, verão que isso é verdade e criarão duas instâncias da classe para cada solicitação feita pelos dois clients. Para resolver isso, a instanciação Thread Safe deve ser implementada.

A segurança (da thread) é fundamental

Em Java, a palavra-chave synchronized é usada nos métodos ou nos objetos para implementar a segurança das threads, de modo que apenas uma thread acesse um recurso específico em determinado momento. A instanciação da classe é colocada dentro de um bloco synchronized para que o método somente possa ser acessado por um client de cada vez.

public class ThreadSafeSingleton {
	// inicializa a instância como null.
	private static ThreadSafeSingleton instance = null;

	// construtor privado, para que ela não possa ser instanciada fora da classe.
	private ThreadSafeSingleton() {  }

	// verifica se a instância é null dentro de um bloco synchronized. Se for, o objeto é criado
	public static ThreadSafeSingleton getInstance() {
		synchronized (ThreadSafeSingleton.class) {
			if (instance == null) {
				instance = new ThreadSafeSingleton();
			}
		}
		return instance;
	}
}

A sobrecarga de um método synchronized é alta, reduzindo o desempenho de toda a operação.

Por exemplo, se a variável de instância já tiver sido instanciada, cada vez que algum client acessar o método getInstance(), o método synchronized é executado e há uma queda de desempenho. Isso acontece apenas para verificar se o valor da variável instance é null. Se descobrir que é, ele sai do método.

Para reduzir essa sobrecarga, é usado o double locking. A verificação é usada antes do método synchronized também. Somente se o valor for null o método synchronized é executado.

// double locking é usado para reduzir a sobrecarga do método synchronized
public static ThreadSafeSingleton getInstanceDoubleLocking() {
	if (instance == null) {
		synchronized (ThreadSafeSingleton.class) {
			if (instance == null) {
				instance = new ThreadSafeSingleton();
			}
		}
	}
	return instance;
}

Sigamos para a próxima classificação.

Tipo 2: estrutural - o padrão de projeto Decorator

Permitam-me apresentar para vocês um pequeno cenário para contextualizar melhor o motivo e as situações nas quais devemos usar o padrão Decorator.

Digamos que você tenha um café e, como qualquer iniciante, você começa com apenas dois tipos de café normal, o da casa e o escuro torrado. Em seu sistema de cobrança, havia uma classe para cada um dos tipos de café, os quais herdam da classe abstrata bebida. A clientela começa a aparecer e a tomar seu maravilhoso (ainda que um tanto amargo) café. Há, porém, aqueles novatos do café, que, Deus me livre!!!, querem tomar café com açúcar ou leite. Nem parece mais café!

Agora, você precisa desses dois adicionais, no menu e, infelizmente, no sistema de cobrança. Originalmente, seu funcionário da TI criará uma subclasse para os dois cafés, um para o café com açúcar e outro para o café com leite. Então, como o cliente tem sempre razão, alguma hora aparecerá um que diga aquelas palavras pavorosas:

"Poderia me dar um café com leite e açúcar, por favor?"

???

Lá vai seu sistema de cobrança rir da sua cara novamente. Bem, de volta à prancheta de desenhos…

O funcionário da TI adiciona café com leite e açúcar para cada classe pai de café. O resto do mês é tranquilo, as pessoas fazem fila para tomar o seu café, e você até está fazendo dinheiro. ??

Mas espere, tem mais!

O mundo vai contra você novamente. A concorrência abre um café do outro lado da rua, não apenas com 4 tipos de café, mas com 10 adicionais! ?

Você compra tudo isso e muito mais para poder vender um café melhor no seu estabelecimento, e é aí que você se lembra de que não atualizou o maldito sistema de cobrança. Possivelmente, você não conseguirá fazer o número infinito de subclasses para toda e qualquer combinação dos adicionais com os novos tipos de café também. Isso para não falar do tamanho final que o sistema terá.??

Está na hora de investir, de fato, em um sistema de cobrança adequado. Você encontra uma nova equipe de TI, que saiba de verdade o que está fazendo, e eles dizem:

"Bem, isso fica muito mais fácil e menor se usarmos o padrão Decorator."

Mas que diabos é isso?

O padrão de projetos Decorator está na categoria estrutural de uma classe, seja por herança, composição ou ambos. O objetivo desse padrão é modificar a funcionalidade de um objeto em tempo de execução. Esse é um dos vários padrões de projetos que usam classes abstratas e interfaces com composição para obter o resultado desejado.

Vamos dar uma chance à matemática (medo!) e colocar isso em perspectiva:

Imagine 4 tipos de café e 10 complementos. Se ficarmos na criação de subclasses para cada combinação diferente de todos os adicionais para um tipo de café, teremos:

(10–1)² = 9² = 81 subclasses

Subtraímos 1 de 10, já que não podemos combinar um adicional com outro do mesmo tipo (açúcar com açúcar parece estúpido). E isso para um único tipo de café. Multiplique esses 81 por 4 e você chega a incríveis 324 subclasses diferentes! Que tal codificar isso tudo?

Porém, com o padrão Decorator, serão necessárias apenas 16 classes para esse cenário. Quer apostar?

Se mapearmos nosso cenário de acordo com o diagrama de classes acima, temos 4 classes para os quatro tipos de café, 10 para cada adicional, 1 para o componente abstrato e mais 1 para o Decorator abstrato. Viram? 16! Agora, me entreguem os $100 dólares da aposta (brincadeira, mas eu não recusaria se me oferecessem…)

Como você pode ver acima, da mesma forma que os tipos concretos de café são subclasses da classe abstrata Beverage (bebida), a classe abstrata AddOn (adicional) também herda seus métodos dela. Os adicionais, que são suas subclasses, por sua vez, herdam todos os novos métodos para acrescentar funcionalidade ao objeto base quando necessário.

Vamos olhar para o código para ver esse padrão em uso.

Primeiro, tornamos a classe Beverage abstrata. É dela que todos os tipos de café herdarão:

public abstract class Beverage {
	private String description;
    
	public Beverage(String description) {
		super();
		this.description = description;
	}
    
	public String getDescription() {
		return description;
	}
    
	public abstract double cost();
}

Em seguida, adicionamos as classes dos tipos de café concretos:

public class HouseBlend extends Beverage {
	public HouseBlend() {
		super(“House blend”);
	}

	@Override
	public double cost() {
		return 250;
	}
}

public class DarkRoast extends Beverage {
	public DarkRoast() {
		super(“Dark roast”);
	}

	@Override
	public double cost() {
		return 300;
	}
}

A classe abstrata AddOn também herdará da classe abstrata Beverage (mais sobre isso abaixo).

public abstract class AddOn extends Beverage {
	protected Beverage beverage;

	public AddOn(String description, Beverage bev) {
		super(description);
		this.beverage = bev;
	}

	public abstract String getDescription();
}

E agora, as implementações concretas dessa classe abstrata:

public class Sugar extends AddOn {
	public Sugar(Beverage bev) {
		super(“Sugar”, bev);
	}

	@Override
	public String getDescription() {
		return beverage.getDescription() + “ with Mocha”;
	}

	@Override
	public double cost() {
		return beverage.cost() + 50;
	}
}

public class Milk extends AddOn {
	public Milk(Beverage bev) {
		super(“Milk”, bev);
	}

	@Override
	public String getDescription() {
		return beverage.getDescription() + “ with Milk”;
	}

	@Override  public double cost() {
		return beverage.cost() + 100;
	}
}

Como você pode ver acima, podemos passar qualquer subclasse de Beverage para qualquer subclasse de AddOn, e obter o custo adicional, assim como a descrição atualizada. Como a classe AddOn é, essencialmente, do tipo Beverage, podemos passar um AddOn em outro AddOn. Dessa forma, podemos acrescentar o número de adicionais que quisermos a um tipo específico de café.

Vamos escrever o código para testar isso:

public class CoffeeShop {
	public static void main(String[] args) {
		HouseBlend houseblend = new HouseBlend();
		System.out.println(houseblend.getDescription() + “: “ + houseblend.cost());

		Milk milkAddOn = new Milk(houseblend);
		System.out.println(milkAddOn.getDescription() + “: “ + milkAddOn.cost());

		Sugar sugarAddOn = new Sugar(milkAddOn);
		System.out.println(sugarAddOn.getDescription() + “: “ + sugarAddOn.cost());
	}
}

O resultado final é:

Funcionou! Conseguimos acrescentar mais de um adicional a um tipo de café e atualizamos com sucesso seu preço final e sua descrição. Vejam que não foi necessário fazer subclasses infinitas para cada combinação de adicional para todos os tipos de café.

Chegamos, finalmente, à última categoria.

Tipo 3: Comportamental - o padrão de projeto Command

O padrão de projeto comportamental tem como foco a maneira como as classes e objetos se comunicam uns com os outros. A ideia central do padrão Command é produzir um maior nível de acoplamento fraco entre as partes envolvidas (leia-se as classes).

Hã… o que é isso?

Acoplamento é a maneira pela qual duas classes (ou mais) interagem umas com as outras. O cenário ideal é quando essas classes interagem sem depender fortemente umas das outras. Esse é o acoplamento fraco. Então, uma definição melhor para o acoplamento fraco seria "classes interconectadas, mas fazendo o menor uso possível umas das outras".

A necessidade desse padrão surgiu quando solicitações precisavam ser enviadas sem que se soubesse conscientemente o que estava sendo solicitado ou quem era o receptor da solicitação.

Neste padrão, a classe que o chama é desacoplada da classe que, de fato, realiza a ação. A classe que chama tem apenas o método de execução para chamar, que executa o comando necessário quando o client o solicita.

Vamos usar um exemplo do mundo real, pedir um prato em um restaurante elegante. O fluxo é: você faz o pedido (comando) ao garçom (quem "invoca" o pedido), que o entregará ao chef (receptor do pedido), para que você possa receber o alimento. Pode parecer simples… mas é um pouco complicado de codificar.

A ideia, de fato, é simples. A codificação, no entanto, é um pouco mais difícil.

O fluxo da operação do lado técnico é: você faz um comando concreto, que implementa a interface Command, pedindo que o receptor realize uma ação e envia o comando a quem invoca o pedido. Essa é a pessoa que sabe a quem dar esse comando. O chef é o único que sabe o que fazer com o comando/pedido específico. Assim, quando o método "execute" daquele que invoca o pedido é executado, ele, por sua vez, faz com que o método execute dos objetos de comando seja passado ao receptor, completando assim as ações necessárias.

O que precisamos implementar:

1. Uma interface Command
2. Uma classe Order (pedido) que implementa a interface Command
3. Uma classe Waiter (Garçom, quem invoca o pedido)
4. Uma classe Chef (o receptor)

Desse modo, o código terá a seguinte aparência:

Chef, o receptor

public class Chef {
	public void cookPasta() {
		System.out.println(“O Chef está fazendo massa ao molho Alfredo…”);
	}

	public void bakeCake() {
		System.out.println(“O Chef está fazendo um bolo de chocolate…”);
	}
}

Command, a interface

public interface Command {
	public abstract void execute();
}

Order (pedido), o comando concreto

public class Order implements Command {
	private Chef chef;
	private String food;

	public Order(Chef chef, String food) {
		this.chef = chef;
		this.food = food;
	}

	@Override
	public void execute() {
		if (this.food.equals(“Massa”)) {
			this.chef.cookPasta();
		} else {
			this.chef.bakeCake();
		}
	}
}

Waiter, (Garçom) quem invoca o pedido

public class Waiter {
	private Order order;

	public Waiter(Order ord) {
		this.order = ord;
	}

	public void execute() {
		this.order.execute();
	}
}

Você, o cliente

public class Client {
	public static void main(String[] args) {
		Chef chef = new Chef();
        
		Order order = new Order(chef, “Massa”);
		Waiter waiter = new Waiter(order);
		waiter.execute();

		order = new Order(chef, “Bolo”);
		waiter = new Waiter(order);
		waiter.execute();
	}
}

Como podemos ver acima, Client faz um Order (pedido) e define o Receiver (Receptor) como sendo o Chef. Order é enviado ao Waiter (Garçom), que saberá quem deve executar o pedido (ou seja, quando dar ao chefe o pedido para que ele o faça). Quando quem invoca o pedido é executado, o método execute de Order é executado no receptor (ou seja, o chef recebe o comando para cozinhar a massa ou para assar o bolo).

Recapitulando

Neste artigo, vimos:

1. O que de fato é um padrão de projetos,
2. Os diferentes tipos de padrão de projetos e o motivo de serem diferentes
3. Um padrão de projetos básico ou comum de padrão de projetos para cada tipo

Espero que isso tenha sido útil.

Encontre o repositório do código para este artigo aqui.