Design Patterns on Dev On Track!

Design Patterns - Bridge

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

Bridge is a structural design pattern that aims to decouple an abstraction of its implementation, in a way that allows both to evolve in an independent way.

This pattern usage is recommended when dealing with classes have many different implementations and use inheritance to implement the abstraction. In those cases, the inheritance connects an implementation to the abstraction permanently, in a way that it’s hard to modify, increase and re-utilize the abstractions in an independent fashion.

To give an illustrated example, let’s pretend that we have a scenario where we want to create different types of bank accounts: CheckingAccount and SavingsAccount. We want our system to be flexible to the creation of new accounts types, so we create an abstract class called BankAccount and extend this class with CheckingAccount and SavingsAccount classes.

Great! Later, we want to give our account types their own personalized credit card type. We create BasicCreditCard, SilverCreditCard and GoldCreditCard classes. When binding those credit card to each bank account type, the problem gets clear:

The naive approach would be to create a combination for each account type, a solution which is costly and grows exponentially (imagine how much work if we add a new account type!). The code is also highly coupled, since different states and behaviors would be contained in a single class.

The Bridge pattern solves this issue by switching from inheritance to composition, and relocating all CreditCard classes to their own hierarchy. By doing that, we allow both contexts to evolve and change independently.

With that design in mind, let’s then create the CreditCard interface:

Now, we’ll create our types: Basic, Silver and Gold, all implementing the methods specified by the interface CreditCard.

Let’s create the abstraction BankAccount, the base class for our account types. This class will have an object of CreditCard, as well as a method to get the card information.

With all created, we can write our account types CheckingAccount and SavingsAccount:

To test our design, we’ll create a main class initializing each account with their respective credit card types.

… which outputs the following content:

In the end, Bridge pattern is a great tool to be used when we want to divide and refactor classes with a lot of variants, and also when we need to extend a class in independent dimensions. A great benefit in using this pattern is that it follows the open/closed principle (since we can add abstractions and implementations without impacting existing ones) and the single responsibility principle.

You can check the full implementation of this example here @ my Github: GracieleDamasceno/design-patterns!

References:

Bridge Pattern - Refactoring Guru

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

Design Patterns - Adapter

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

Adapter is a design pattern with the purpose of - as the name suggests - adapt one context to another, allowing two incompatible interfaces to be connected.

The main benefit of applying this pattern is to allow switching from an existing interface to another without changing the original behavior of the existing interface. Adapter is also used when there’s the necessity of creating a reusable class that interacts with incompatible interfaces.

Let’s see this pattern in action!

Adapting an existing output to a new one

In our scenario, we have a Person POJO that contains a few attributes.

There’s also an interface that dictates the contract of a Person. In our case, the existing contract states that the Person output should be a string formatted in XML.

And the LegacyPersonService implements that contract, building a Person object and returning it in XML written as string.

This architecture works well for quite a while, until we have to redesign our system. Since we have a lot of external and crucial dependencies, the XML output has to coexist with the new solution, which has the objective to output the Person object as a string in JSON format.

That’s exactly when the adapter pattern comes in handy!

We are going to adapt our previous solution to generate a JSON, following the new requirements. First, let’s implement an interface that carries this new contract.

Now, we create the adapter: implementing the interface created earlier, we instantiate the LegacyPersonService class that contains the logic of the old contract and implement the new logic to transform the response into a string in JSON.

With that created, we can safely create a new version of our endpoint which serves the new specification, without changing the existing one.

So, to summarize:

The adapter pattern follows the open-closed principle. We can add new adapters without altering the existing code.
The adapter pattern also follows the single responsibility principle, since we separated the interface/contract from the existing business logic.
In our case, it was used composition at ModernizedPersonAdapter to wrap the target of the adapter (LegacyPersonService). This way of dealing with the adaptee class is called Object Adapter.
- The other way of implementing an adapter would be using the Class Adapter style, where instead of creating a LegacyPersonService object in ModernizedPersonAdapter, we would simultaneously extend LegacyPersonService and implement PersonOutputAdapter. Both are valid approaches, however, it’s best to favor composition over inheritance, since it allows the system to be easier to test, less complex and decoupled.
The main disadvantage that this pattern offers is the increase in complexity when adding new components to the application. Depending on the situation and external constraints, it’s better to just refactor the existing code to match the new contract.

You can check the full implementation displayed here @ my Github: GracieleDamasceno/design-patterns! Till next time!

References:

Composition over inheritance - Wikipedia

Adapter Pattern - Refactoring Guru

Design Patterns - Prototype

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

Following our series of design patterns, the second one that we will revisit is Prototype!

This pattern aims to have a “blueprint” to generate instances. This is very handy in situations where exists multiple objects with different properties, it is expensive to create new resources and when we want to specify the class instantiation during run-time.

Basically, to implement a Prototype, we have to add to the desired original class a method that clones an instance based on the original. The next step is to create a “registry” that maintains a cache of the prototypical objects; followed by a factory class that clones the original and returns the result.

The clone process is a main aspect of prototype, so, to better understand the nuances hidden in cloning an object, let’s talk about deep cloning and shallow cloning.

Deep Cloning versus Shallow Cloning

Deep cloning means when cloning, each copy will have their own reference. If we change an attribute of the copy, the original will remain intact.

The same doesn’t happen when shallow cloning: both copy and original shares the same reference. This means that changes made to copy attributes will also be reflected in the original attributes object.

Implementing Prototype Pattern in Java

There’s a few “gotchas” while implementing Prototype in Java: The obvious choice, Java’s Cloneable interface, is commonly known to be flawed. There’s simply no built mechanism in Java to create deep copies, which means that implementing Cloneable and calling super.clone() will always create a shallow copy either way. Even worse, the interface Cloneable is a marker class that just marks the class that implements it as suitable for cloning, and doesn’t have itself a clone() method (this method being presented in the Object class instead).

Those factors argue to be a better choice to use copy constructors to create a clone instead of Java’s Cloneable.

With that in mind, let’s attempt to use Prototype to solve a problem. The concept is as follows: We want to keep track of some Cryptocurrencies that were bought on January 1st, 2022. The snapshot of the values at this period of time populates the original instance when the application starts. The user sends their choice of Cryptocurrency and the application calls an endpoint to get real-time information about that specific Crypto, calculates the difference between then and now in a report.

This is the application architecture diagram:

The application controller is as follows:

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

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

The controller will then call the 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;
 }
}

This is the class that mappers the object received by the request to the instance 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;
 }
}

The class that loads the original instance of 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);
 }
}

Finally, the Cryptocurrency class that performs the cloning in the constructor:

@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());
 }
}

You can check the full project implementation clicking here.

References

Interesting conversations about Java’s Cloneable:

Java: Clone and Cloneable > Programming.Guide

Java Cloning Problems > Vojtech Ruzicka’s Programming Blog

Copy constructors > Java Practices

Design Patterns - Factory

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

Today we are going to take a close look at Factory Design Pattern.

Imagine that you have a requirement to build an application feature that sends a message specified by a user through different delivery methods. For example, they can send their message using SMS, push notification to a mobile phone, email…

It would be such a hassle to build different classes to receive the user message to deliver it! I mean, imagine if the user has to memorize different endpoints/arguments to send their message. Looking at the code, we would have to create a method that would call each of the classes that would send a message using a specific way. But what if I want to develop another message delivery type? I would have to touch the logic that controls each message to their respective type, and if I’m not careful enough, I could delete or modify important pieces of that logic. My code would have lots of conditions and could be highly coupled.

The Factory Patterns suggests a pretty neat way to solve that problem. Let’s see how!

Show me the code!

First, let’s take a look at our architecture diagram.

The main idea is to create a notification interface that will have a delivery method defined, so that each of the classes will implement their own specifics of the delivery. There’s five delivery method defined, and those methods will be called based on a parameter sent by the user through a service. We will get more details about it in a bit.

The project uses Java with Spring and a REST call to send a message. Let’s start by creating a REST controller where the user can post their message and the selected delivery type.

@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);
 }
}

We have created a MessageRequestDTO that encapsulates a String attribute message, and an enum class called NotificationTypeEnum with all of our delivery options.

The interface that specifies our delivery method is as follows:

public interface Notification {

 DeliveryResponseDTO deliverMessage(MessageRequestDTO message);
}

And this is an example of our delivery class implementing Notification interface:

@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();
 }
}

Great, now, let’s create the class NotificationService that will handle the dispatch of our message request from the controller.

@NoArgsConstructor
@Service
public class NotificationService {

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

Hang on… There’s not much happening here. We created a method to redirect the message by receiving the message itself and the method of delivery, which is an enum. Apparently, there’s a method inside our enum to get the instance of the NotificationType… Let’s take a closer look at how the enum class was created.

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();
}

This is the most interesting class in the project, in my opinion. We are applying a cool concept here - creating a getInstance method which redirects returns the correct class of delivery based on the enum sent by the user. That way, we avoid if statements and our code becomes more clean and efficient.

It’s possible to notice that we didn’t have to call any of our delivery classes - neither any of the service nor controller classes had to. If we wanted to add a new delivery type, we wouldn’t have to touch any of the other delivery classes, they wouldn’t even “notice” the addition or removal of such delivery method. This happens because our logic of constructing a class is held by only one “factory” class, in this case, NotificationTypeEnum.

So, to put it simply, Factory works by creating an interface that creates families of objects that have the similar function but different behavior, without the need of specifying the concrete class of those objects. The Factory-part lies in creating mechanisms that deal with selecting the correct implementation for each case needed.

That’s it! You can check the full project implementation clicking here.