Padrões De Projeto on Dev On Track!

Padrões de Projeto - Bridge

Fri, 03 Mar 2023 08:00:00 +0000

Bridge é um padrão de projeto estrutural que visa desacoplar uma abstração de sua implementação, de forma que permita que ambos evoluam de forma independente.

O uso desse padrão é recomendado ao lidar com classes que possuem muitas implementações diferentes e usam herança para implementar a abstração. Nesses casos, a herança conecta uma implementação à abstração permanentemente, de forma que é difícil modificar, aumentar e reutilizar as abstrações de forma independente.

Para dar um exemplo ilustrado, vamos fingir que temos um cenário onde queremos criar diferentes tipos de contas bancárias: CheckingAccount e SavingsAccount. Queremos que nosso sistema seja flexível para a criação de novos tipos de contas, então criamos uma classe abstrata chamada BankAccount e estendemos esta classe com as classes CheckingAccount e SavingsAccount.

Ótimo! Mais tarde, queremos dar aos nossos tipos de conta seu próprio tipo de cartão de crédito personalizado. Criamos as classes BasicCreditCard, SilverCreditCard e GoldCreditCard. Ao vincular esses cartões de crédito a cada tipo de conta bancária, o problema fica claro:

A abordagem ingênua seria criar uma combinação para cada tipo de conta, uma solução que é cara e cresce exponencialmente (imagine o tanto de trabalho se adicionarmos um novo tipo de conta!). O código também é altamente acoplado, pois estados e comportamentos diferentes estariam contidos em uma única classe.

O padrão Bridge resolve esse problema mudando de herança para composição e realocando todas as classes CreditCard para sua própria hierarquia. Ao fazer isso, permitimos que ambos os contextos evoluam e mudem independentemente.

Com esse design em mente, vamos então criar nossa interface CreditCard:

Agora, vamos criar nossos tipos: Basic, Silver e Gold, todos implementando os métodos especificados pela interface CreditCard.

Vamos criar a abstração BankAccount, a classe base para nossos tipos de conta. Esta classe terá um objeto CreditCard, bem como um método para obter as informações do cartão.

Com tudo criado, podemos escrever nossos tipos de conta CheckingAccount e SavingsAccount:

Para testar nosso projeto, criaremos uma classe principal inicializando cada conta com seus respectivos tipos de cartão de crédito.

…que gera o seguinte conteúdo:

No fim das contas, o padrão Bridge é uma ótima ferramenta para ser utilizada quando queremos dividir e refatorar classes com muitas variantes, e também quando precisamos estender uma classe em dimensões independentes. Um grande benefício em usar esse padrão é que ele segue o princípio aberto/fechado (já que podemos adicionar abstrações e implementações sem afetar as existentes) e o princípio de responsabilidade única.

Você pode verificar a implementação completa deste exemplo aqui no meu Github: GracieleDamasceno/design-patterns!

Referências:

Bridge Pattern - Refactoring Guru

Design Patterns (2005), By Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Craig Larman

Padrões de Projeto - Adapter

Sat, 18 Feb 2023 08:00:00 +0000

Adapter é um padrão de projeto com a finalidade de - como o próprio nome sugere - adaptar um contexto à outro, permitindo que duas interfaces incompatíveis sejam conectadas. O principal benefício de aplicar esse padrão é permitir trocar de uma interface existente para outra sem alterar o comportamento original da interface existente. o Adapter também é usado quando há a necessidade de criar uma classe reutilizável que interaja com interfaces incompatíveis. Vamos ver esse padrão em ação!

Adaptando a saída existente para uma nova

Em nosso cenário, temos uma POJO de pessoa que contém alguns atributos.

Existe também uma interface que dita qual será o contrato de negócio do objeto Pessoa. Em nosso caso, o contrato existente estabelece que a resposta da classe Person deve ser uma string formatada em XML.

E a classe LegacyPersonService implementa esse contrato, construindo um objeto da classe Person e retornando-o em string, formatada em XML.

Essa arquitetura funciona bem por um bom tempo, até que seja necessário redesenhar nosso sistema. Como nesse cenário temos muitas dependências externas e cruciais, a resposta em XML tem que coexistir com a nova solução, que tem como objetivo ter a resposta em string no formato JSON.

É exatamente aí que o padrão do adaptador é muito útil!

Vamos adaptar nossa solução anterior para gerar um JSON, seguindo os novos requisitos. Primeiro, vamos implementar uma interface que dite esse novo contrato.

Agora, criamos o adapter: implementando a interface criada anteriormente, instanciamos a classe LegacyPersonService que contém a lógica do contrato antigo e implementamos a nova lógica para transformar a resposta em uma string em JSON.

Com a lógica criada, podemos criar tranquilamente uma nova versão do nosso endpoint que atenda à nova especificação, sem alterar a que já existia.

Então, para resumir:

O padrão de Adapter segue o princípio aberto-fechado. Podemos adicionar novos adaptadores sem alterar o código existente.
O padrão de Adapter também segue o princípio da responsabilidade única, pois separamos a interface/contrato da lógica de negócios existente.
No nosso caso, foi utilizada composição na classe ModernizedPersonAdapter para encapsular o alvo do adaptador (LegacyPersonService). Esta forma de lidar com a classe adaptada é chamada de Object Adapter.
- A outra forma de implementar um adaptador seria usando o estilo Class Adapter, onde ao invés de criar um objeto LegacyPersonService em ModernizedPersonAdapter, estenderíamos LegacyPersonService e implementaríamos PersonOutputAdapter simultaneamente. Ambas são abordagens válidas, no entanto, é melhor favorecer a composição em detrimento da herança, pois permite que o sistema seja mais fácil de testar, menos complexo e desacoplado.
A principal desvantagem que esse padrão oferece é o aumento da complexidade ao adicionar novos componentes à aplicação. Dependendo da situação e das restrições externas, é melhor apenas refatorar o código existente para corresponder ao novo contrato.

Você pode dar uma olhada no código aqui no meu Github: GracieleDamasceno/design-patterns! Até a próxima!

Referências:

Composition over inheritance - Wikipedia

Adapter Pattern - Refactoring Guru

Padrões de Projeto - Prototype

Fri, 04 Nov 2022 08:00:00 +0000

Continuando nossa série de padrões de projeto, o segundo que iremos revisitar é o Prototype!

Este padrão visa ter um “planta” para gerar instâncias. Isso é muito útil em situações onde existem vários objetos com propriedades diferentes, onde seja custoso criar novos recursos e quando queremos especificar a instanciação da classe em tempo de execução.

Basicamente, para implementar um Prototype, temos que adicionar à classe original desejada um método que clona uma instância baseada na original. O próximo passo é criar uma espécie de “registro” que mantenha um cache dos objetos prototipados; seguido por uma classe de fábrica que clona o original e retorna o resultado.

O processo de clonagem é um dos aspecto mais importantes do Prototype, então, para entender melhor as nuances escondidas na clonagem de um objeto, vamos falar sobre Deep Cloning e Shallow Cloning.

Deep Cloning versus Shallow Cloning

Deep Cloning significa que, ao clonar, cada cópia terá sua própria referência. Se alterarmos um atributo da cópia, o original permanecerá intacto.

O mesmo não acontece com o Shallow Cloning: tanto a cópia quanto o original compartilham a mesma referência. Isso significa que as alterações feitas nos atributos de cópia também serão refletidas nos atributos do objeto original.

Implementando o Padrão Prototype em Java

Existem algumas “pegadinhas” ao implementar o Prototype em Java: A escolha óbvia, a interface Cloneable do Java, é comumente conhecida por ser defeituosa. Simplesmente não existe um mecanismo construído em Java para criar “deep clones” nativamente, o que significa que implementar Cloneable e chamar super.clone() sempre criará uma cópia superficial. Pior ainda, a interface Cloneable é uma classe marker que apenas marca a classe que a implementa como adequada para clonagem, e não possui um método clone() próprio (este método existe na classe Object).

Esses fatores argumentam por ser uma escolha melhor usar cópia via construtores para criar clones ao invés do Cloneable do Java.

Com isso em mente, vamos tentar usar o Prototype para resolver um problema. O conceito é o seguinte: Queremos acompanhar algumas Criptomoedas que foram compradas em 1º de janeiro de 2022. Os valores nesse período preenchem a instância original quando o aplicativo é iniciado. O usuário envia sua escolha de criptomoeda e o aplicativo chama um endpoint para obter informações em tempo real sobre essa criptomoeda específica, calcula a diferença entre o antes e o depois e envia de volta em um relatório.

Esse é o diagrama de arquitetura do aplicativo:

A classe de controller da aplicação é a seguinte:

@RestController
@AllArgsConstructor
public class CryprocurrencyController {
 private final CryptocurrencyService cryptocurrencyService;

 @GetMapping(value = "/crypto/{cryptocurrencyType}")
 public CryptocurrencyReport cryptocurrencyController(@PathVariable CryptocurrencyTypeEnum cryptocurrencyType) {
 return cryptocurrencyService.getCryptocurrencyReport(cryptocurrencyType);
 }
}

Então, o controller invoca a service:

@Service
@AllArgsConstructor
public class CryptocurrencyService {

 private final CryptocurrencyClient cryptocurrencyClient;
 private final CryptocurrencyLoader cryptocurrencyLoader;

 public CryptocurrencyReport getCryptocurrencyReport(CryptocurrencyTypeEnum cryptocurrencyTypeEnum){

 //Get original Cryptocurrency instance
 Cryptocurrency cryptocurrencyAtPurchase = cryptocurrencyLoader.getCryptocurrencyLoaded(cryptocurrencyTypeEnum);

 //Get Cryptocurrency cloned with updated values
 Cryptocurrency cryptocurrencyNow = getUpdatedCryptocurrencyValues(cryptocurrencyTypeEnum);

 //Returns the report calculating variation between purshased value and current value
 return CryptocurrencyReport.builder()
 .cryptocurrencyCurrentValues(cryptocurrencyNow)
 .cryptocurrencyPurchaseValues(cryptocurrencyAtPurchase)
 .rankVariation(calculateVariation(cryptocurrencyAtPurchase.getRank(), cryptocurrencyNow.getRank()))
 .priceUSDVariation(calculateVariation(cryptocurrencyAtPurchase.getPriceUSD(), cryptocurrencyNow.getPriceUSD()))
 .volume24Variation(calculateVariation(cryptocurrencyAtPurchase.getVolume24(), cryptocurrencyNow.getVolume24()))
 .marketCapUSDVariation(calculateVariation(cryptocurrencyAtPurchase.getMarketCapUSD(), cryptocurrencyNow.getMarketCapUSD()))
 .build();
 }

 private Cryptocurrency getUpdatedCryptocurrencyValues(CryptocurrencyTypeEnum cryptocurrencyTypeEnum){
 //Requests current Crypto's data 
 final CryptocurrencyDTO cryptocurrencyDTO =
 cryptocurrencyClient.getCryptocurrency(cryptocurrencyTypeEnum.getId()).iterator().next();
 //Loads original cripto values
 Cryptocurrency cryptocurrencyLoaded = cryptocurrencyLoader.getCryptocurrencyLoaded(cryptocurrencyTypeEnum);
 //Maps the current values to the original Criptocurrency object
 return updateLoadedPrototypeWithCurrentValues(cryptocurrencyDTO, cryptocurrencyLoaded);
 }

 private BigDecimal calculateVariation(BigDecimal valueBefore, BigDecimal valueNow){
 return valueNow.subtract(valueBefore);
 }

 private Integer calculateVariation(Integer valueBefore, Integer valueNow){
 return valueNow - valueBefore;
 }
}

Essa é a classe que realiza o mapeamento do objeto recebido para o clone:

@NoArgsConstructor
public class CryptocurrencyDTOMapper {

 public static Cryptocurrency updateLoadedPrototypeWithCurrentValues(CryptocurrencyDTO cryptocurrencyDTO, Cryptocurrency cryptocurrencyLoaded){
 cryptocurrencyLoaded.setRank(cryptocurrencyDTO.getRank());
 cryptocurrencyLoaded.setPriceUSD(cryptocurrencyDTO.getPriceUSD());
 cryptocurrencyLoaded.setVolume24(cryptocurrencyDTO.getVolume24());
 cryptocurrencyLoaded.setMarketCapUSD(cryptocurrencyDTO.getMarketCapUSD());
 return cryptocurrencyLoaded;
 }
}

A classe que carrega a instância de Cryptocurrency:

@Component
public class CryptocurrencyLoader {

 HashMap<String, Cryptocurrency> cryptocurrencyTable = new HashMap<>();
 //Returns crypto object based on the enum requested by the user
 public Cryptocurrency getCryptocurrencyLoaded(CryptocurrencyTypeEnum crypto){
 Cryptocurrency loadedCryptocurrency = cryptocurrencyTable.get(crypto.getId());
 //Here the cloning happens!
 return new Cryptocurrency(loadedCryptocurrency);
 }

 //Loads the crypto information on application startup
 @PostConstruct
 private void loadCryptoInfo1stJanuary2022(){
 Cryptocurrency bitcoin = Cryptocurrency.builder()
 .id(CryptocurrencyTypeEnum.BTC.getId())
 .name("BITCOIN")
 .symbol(CryptocurrencyTypeEnum.BTC)
 .rank(1)
 .volume24(new BigDecimal("24582667004"))
 .priceUSD(new BigDecimal("47686.81"))
 .marketCapUSD(new BigDecimal("902104193385"))
 .build();

 Cryptocurrency ethereum = Cryptocurrency.builder()
 .id(CryptocurrencyTypeEnum.ETH.getId())
 .name("ETHEREUM")
 .symbol(CryptocurrencyTypeEnum.ETH)
 .rank(1)
 .volume24(new BigDecimal("9776191466"))
 .priceUSD(new BigDecimal("3769.70"))
 .marketCapUSD(new BigDecimal("448537615143"))
 .build();

 cryptocurrencyTable.put(CryptocurrencyTypeEnum.BTC.getId(), bitcoin);
 cryptocurrencyTable.put(CryptocurrencyTypeEnum.ETH.getId(), ethereum);
 }
}

Finalmente, a classe de Cryptocurrency que realiza a clonagem através do construtor com um parâmetro:

@Getter
@Setter
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class Cryptocurrency {

 private String id;

 private CryptocurrencyTypeEnum symbol;

 private String name;

 private Integer rank;

 @JsonProperty("price_usd")
 private BigDecimal priceUSD;

 @JsonProperty("volume_24")
 private BigDecimal volume24;

 @JsonProperty("market_cap_usd")
 private BigDecimal marketCapUSD;

 /*
 * Since the clone method from Cloneable class is broken, we use a copy constructor.
 * */
 public Cryptocurrency(Cryptocurrency cryptocurrency) {
 this(cryptocurrency.getId(),
 cryptocurrency.getSymbol(),
 cryptocurrency.getName(),
 cryptocurrency.getRank(),
 cryptocurrency.getPriceUSD(),
 cryptocurrency.getVolume24(),
 cryptocurrency.getMarketCapUSD());
 }
}

Você pode checar a implementação completa do projeto clicando aqui.

Referências

Discussões interessantes sobre o Cloneable do Java:

Java: Clone and Cloneable > Programming.Guide

Java Cloning Problems > Vojtech Ruzicka’s Programming Blog

Copy constructors > Java Practices

Padrões de Projeto - Factory

Mon, 29 Aug 2022 08:00:00 +0000

Hoje vamos dar uma olhada no Padrão de Projeto “Factory”.

Imagine que você tenha que construir uma applicação que envie uma mensagem especificada pelo usuário usando diferentes métodos de entrega. Por exemplo, o usuário poderia enviar sua mensagem usando SMS, uma notificação push para um celular, e-mail…

Seria um incômodo construir muitas classes diferentes para receber a mensagem do usuário e entregá-la! Quero dizer, imagine se o usuário tiver que utilizar diferentes endpoints/argumentos para enviar cada tipo de mensagem. Pensando em código, teríamos que criar um método que chamasse cada uma das classes que enviariam uma mensagem de cada maneira específica. Mas e se eu quiser desenvolver outro tipo de método de entrega? Eu teria que alterar a lógica que envia cada mensagem para seu respectivo tipo e, se não tomar cuidado, poderia excluir ou modificar partes importantes dessa lógica. Meu código teria muitas condições e poderia ser altamente acoplado.

Os Padrões de Projeto sugerem uma maneira bem legal de resolver esse problema. Vamos ver como!

Mãos a obra!

Primeiro, vamos dar uma olhadinha no nosso diagrama de arquitetura.

A ideia principal é criar uma interface de notificação que terá um método de entrega definido, para que cada uma das classes implemente suas próprias especificidades da entrega. Há cinco métodos de entrega definidos, e esses métodos serão chamados com base em um parâmetro enviado pelo usuário por meio de uma classe de service. Daqui a pouco vamos ver mais detalhes sobre isso.

Esse projeto usa Java com Spring, e uma chamada REST para receber a mensagem desejada. Vamos começar criando um controller REST onde o usuário pode postar sua mensagem e o tipo de entrega selecionado.

@Slf4j
@RestController
@AllArgsConstructor
public class NotificationController {

 private NotificationService notificationService;

 @PostMapping(value = "/message")
 public DeliveryResponseDTO sendMessage(@RequestBody MessageRequestDTO message, @RequestParam NotificationTypeEnum delivery) {
 log.info("Message received. Method of delivery: " + delivery + ". Payload: " + message);

 return notificationService.redirectMessage(message, delivery);
 }
}

Criamos uma classe MessageRequestDTO que encapsula uma mensagem de tipo String e uma classe enum chamada NotificationTypeEnum com todas as nossas opções de entrega.

A interface que especifica nosso método de entrega padrão para todas as opções de entrega é a seguinte:

public interface Notification {

 DeliveryResponseDTO deliverMessage(MessageRequestDTO message);
}

E este é um exemplo de nossa classe de entrega implementando a interface Notification:

@Slf4j
public class CarrierPigeonNotification implements Notification {

 @Override
 public DeliveryResponseDTO deliverMessage(MessageRequestDTO message) {
 log.info("Carrier Pigeon is the selected choice of delivery! The message to send is: " + message);

 return DeliveryResponseDTO.builder()
 .delivered(false)
 .deliveryStatus("Delivery method not yet supported!")
 .build();
 }
}

Maravilha, agora vamos criar a classe NotificationService que tratará o envio da nossa requisição de mensagem vinda do controller.

@NoArgsConstructor
@Service
public class NotificationService {

 public DeliveryResponseDTO redirectMessage(MessageRequestDTO message, NotificationTypeEnum methodOfDelivery){
 Notification notification = methodOfDelivery.getInstance();
 return notification.deliverMessage(message);
 }
}

Pera aí… Não tem muita coisa acontecendo aqui. Criamos um método para redirecionar a mensagem recebendo o próprio DTO de mensagem e o método de entrega, que é um enum. Aparentemente, existe um método dentro do nosso enum para obter a instância do NotificationType… Vamos dar uma olhada em como a classe enum foi criada.

public enum NotificationTypeEnum {
 CARRIER_PIGEON {
 public CarrierPigeonNotification getInstance(){
 return new CarrierPigeonNotification();
 }
 },
 EMAIL {
 public EmailNotification getInstance(){
 return new EmailNotification();
 }
 },
 MAIL_LETTER {
 public MailLetterNotification getInstance(){
 return new MailLetterNotification();
 }
 },
 MOBILE_PUSH {
 public MobilePushNotification getInstance(){
 return new MobilePushNotification();
 }
 },
 SMS{
 public SMSNotification getInstance(){
 return new SMSNotification();
 }
 };

 public abstract Notification getInstance();
}

Essa é a classe mais interessante de todo o projeto, na minha opinião. Estamos aplicando um conceito bem legal aqui - criando um método getInstance que retorna a classe correta de entrega com base no enum enviado pelo usuário. Dessa forma, evitamos blocos if e nosso código se torna mais limpo e eficiente.

É possível notar que não tivemos que chamar nenhuma de nossas classes de entrega - nem as classes de service nem de controller precisaram chamar. Se quiséssemos adicionar um novo tipo de entrega, não teríamos que mexer em nenhuma das outras classes de tipo de entrega, elas nem “perceberiam” a adição ou remoção de tal método de entrega. Isso acontece porque nossa lógica de construção das instancias das classes é mantida por apenas uma classe usada como “fábrica”, neste caso, a NotificationTypeEnum.

Então, para simplificar, o Factory funciona criando uma interface que é responsável por criar famílias de objetos que possuem a mesma “função”, mas com comportamento diferente, sem a necessidade de especificar qual é a classe concreta desses objetos. A parte de ser uma fábrica está na criação de mecanismos que tratam de selecionar a implementação correta para cada caso necessário.

É isso! Você pode conferir a implementação completa desse exemplo de factory clicando aqui.