Forem: Gabriel Ong

Functional Programming Design Patterns: Part 2 - Factory Method Pattern

Gabriel Ong — Sun, 15 Nov 2020 15:57:48 +0000

This post is Part 2 of a series on utilizing Design Patterns in the context of Functional Programming. If you are interested in learning more, stay tuned for more on my DEV page.

Introduction

As mentioned in the first part of the series, design patterns in Software Engineering (SE) have been widely popularized by the book Design Patterns: Elements of Reusable Object-Oriented Software written by the Gang of Four (GoF).

The book further categorizes design patterns into what kind of problems these patterns are designed to solve, namely the following categories:

Creational - Patterns that provide ways to instantiate single or groups of objects.
Structural - Patterns that provide ways to define relationships between classes and objects.
Behavioural - Patterns that define manners of communication between classes and objects.

Previously, we looked at the Strategy Pattern, which is a Behavioural pattern.

You can learn more about the categorization of the different patterns using this excellent page by Vince Huston.

Vince's Periodic Table inspired diagram on Design Patterns.
[It's interactive too!](http://www.vincehuston.org/dp/)

For this article, we'll take a look at a Creational pattern: the Factory Method pattern.

The Factory Method Pattern

The Factory Method design pattern describes exposing a factory method in a Creator class without specifying the exact Product class that will be created. The factory method lets the Creator class defer instantiation of Products to its subclasses.

Whew! Once again, what a mouthful.

Let's break this definition down like we did last time. We have a few key components here:

Creator - An interface or abstract class that defines a factory method which returns a Product.
Product - An interface or abstract class that provides an abstract layer of reference to a concrete product.
Factory Method - A method that is implemented by concrete creators, which specific a concrete product to return.

If this is confusing, do not fret! This is easier to visualize with some examples!

Retail Store Example

In the spirit of the previous article, let us use the same Retail Store example but in a different problem context.

Suppose that for the retail store, we want to introduce a simulator to better estimate our business. In our simulator, we have two different "customer modes" we can select, where we can simulate a really bad and picky customers, or simulate a really good and gracious customers.

We want to differentiate the way we deal with creating the different Customers but without affecting the rest of the simulator code. We can implement the Factory Method pattern as follows:



interface CustomerCreator {
    public Customer createCustomer();
}

interface Customer {
    public boolean isGood();
}

class GoodCustomerCreator implements CustomerCreator {
    public Customer createCustomer() {
        return new GoodCustomer();
    }
}

class BadCustomerCreator implements CustomerCreator {
    public Customer createCustomer() {
        return new BadCustomer();
    }
}

class GoodCustomer implements Customer {
    public boolean isGood() {
        return true;
    }
}

class BadCustomer implements Customer {
    public boolean isGood() {
        return false;
    }
}

As you can see, we can easily decouple the logic of having different ways to create and represent products. This pattern really shines when:

There are an increasing number of different ways of create products. Let say for example, in our store simulator, we now want a way that will randomly return us a Good or Bad customer. We can simply create a RandomCustomerCreator and encapsulate the randomizing logic there. Our parent process will still only have to maintain a reference to a Creator class.
There are an increasing number of products. Similarly, we only need to implement the Customer interface for any new customers and implement any additional logic there.

The Functional Approach

Let's see Strategy Pattern implemented in a Functional Programming-friendly way.

Currying

For this pattern, we can take advantage of a concept known as Currying. Currying is the concept mostly seen in functional programming and mathematics as the process where a function taking multiple arguments can be transformed into a function that takes in only a single argument while returning another function which accepts further arguments.

Another wordy definition! Let us illustrate this with a simple example:

Let us implement a function to add three numbers together:



const addMyTriple = (a, b, c) => {
    return a + b + c;
}

addMyTriple(1, 2, 3) // Returns 6.

Currying this function would give us the following:



const addMyTriple = (a) => {
    return (b) => {
        return (c) => {
            return a + b + c;
        }
    }
}
addMyTriple(1)(2)(3) // Returns 6.

This looks like a we're just increasing the verbosity of our function doesn't it? But the key is in realizing that we're returning the inner function every time. Suddenly, this becomes invaluable as we can fix variables and form other functions by using currying.

Here's an example. Let's say we want to add three numbers like before, but now we want to fix the first number to always be 10.

We can simply compose a new function by doing this:



const addMyDoublePlusTen = addMyTriple(10);

addMyDoublePlusTen(2,3) // Returns 15.

Now let us apply this in implementing the Factory Method Pattern.



const customerCreator = (isGood) => {
    return isGood ? goodCustomer : badCustomer;
}

const customer = (isGood) => {
    return {
        isGood: isGood
    };
}

const goodCustomerCreator = () => {
    return customerCreator(true);
}

const badCustomerCreator = () => {
    return customerCreator(false);
}

const goodCustomer = () => {
    return customer(true);
}

const badCustomer = () => {
    return customer(false);
}

As you can see, we utilize currying here to differentiate the different creator functions by their type. We do that similarly for the customers themselves.

While this example seems intuitive, the key to understanding when to use the pattern is in two key nuances:

How do you want to your instantiate objects? (Order, Composition, Configurations, etc.)
How to represent the different types of objects? (Data Structure, etc.)

You might realize that this pattern maintains encapsulation of logic really nicely, even as the complexity of the example grows (which ties in with the whole point of using design patterns)!

Extending the example

To catalyze your learning process, think about some of the following questions and how you would implement them:

Suppose in our simulator we maintain a list of 10 Customers. How would you implement the Creators for a good day and a bad day?
What if there were instead 3 types of Customer? (Good, Bad, Neutral)

What's next

This post is Part 2 of a series on utilizing Design Patterns in the context of Functional Programming. If you are interested in learning more, stay tuned for more on my DEV page.

Functional Programming Design Patterns: Part 1 - Strategy Pattern

Gabriel Ong — Sun, 15 Nov 2020 12:52:25 +0000

This post is Part 1 of a series on utilizing Design Patterns in the context of Functional Programming. If you are interested in learning more, stay tuned for more on my DEV page.

Introduction

Made ubiquitous by the indispensable book Design Patterns: Elements of Reusable Object-Oriented Software written by the Gang of Four, Design Patterns in Software Engineering (SE) are often utilized as battle-tested ways to solve recurrent system design problems in a flexible and reusable way.

The now must-have book in every Software Engineer's bookshelf. [source]

However, Design Patterns are more often than not, are utilized in an Object-Oriented Programming (OOP) fashion. Many patterns include the use of abstract classes, interfaces and other OOP features that do not make sense in the context of Functional Programming (FP), where whole systems are composed of functions instead of concrete classes.

Thus, this poses a sort of cognitive mismatch for many engineers who have internalized these OOP patterns and are finding themselves in an environment where FP is growing in popularity.

This post and the subsequent series seeks to provide some instruction and examples on using some of these patterns in the context of FP.

The Strategy Pattern

The Strategy Pattern from the GoF book is described as a way to vary a family of encapsulated algorithms to make them interchangeable from a runtime context. That definition can be a mouthful, so let's break it down.

We have a few components here:

Algorithm - A procedure that takes some value as input, performs some steps on the input, and produces an output.
Strategy - A common interface implemented by all Algorithms.
Context - A Run-time environment or a parent process that seeks to utilize a different algorithm given some condition.

Retail Store Example

To make it easier to understand this, let us adapt this pattern in a real-life context:

Suppose we have a retail store and we want to introduce a way to implement different pricing algorithms to calculate the total price of a customer's order depending on the type of a customer (walk-in or online).

We can first define our pricing algorithms as follows:

Strategy and Algorithms



interface PricingStrategy {
    public float getTotalPrice(CustomerOrder);
}

class WalkInPricing implements PricingStrategy {
  public float getTotalPrice(CustomerOrder order) {
      // Calculate the price per item in order
      // according to the walk-in pricing
      ...
      return totalPrice;
  }
}

class OnlinePricing implements PricingStrategy {
  public float getTotalPrice(CustomerOrder order) {
      // Calculate the price per item in order
      // according to the online pricing
      ...
      return totalPrice;  
  }
}

Following that, we can then introduce the strategy and algorithms to the context, like so:

Context



PricingStrategy pricing;
...
// First, we decide type of customer and pricing algorithm to use.
switch(customer.type) {
    case "walkIn":
      this.pricing = new WalkInPricing();
      break;
    case "online":
      this.pricing = new OnlinePricing();
      break;
    default:
      throw new IllegalCustomerType("...");
}

// Secondly, we get the calculated total price for the order using the pricing algorithm.
this.totalPrice = this.pricing.getTotalPrice(customer.order);
...

This is pretty simple and intuitive!

There are a few benefits to designing the variation this way:

We avoid implementing a single brittle monolithic algorithm that accounts for all the conditions. Or even implementing the logic in Context itself! (e.g. Implementing a PricingAlgorithm class that has a lot of if/else and switch statements to check the customer type).
We introduce extensibility by encapsulating the algorithms separately. If we want to introduce a new pricing algorithm for a new customer type, we simply need to extend the switch statement in Context and have the new pricing algorithm implement the Strategy interface.

The Functional Approach

Now that we've established how to use the Strategy Pattern in an OOP fashion, how do we implement the same kind of logic in a FP-friendly way?

Well, quite simply we can leverage the idea of higher-order functions, where functions can take in other functions as parameters.



const getMathResult = (mathOperation, arguments) => {
    return mathOperation(arguments);
};

A simple higher-order function.

This allows us to represent a similar abstraction provided by using an interface in OOP!

Let us explore how we can do this:



const walkInPricing = (orders: CustomerOrder): Number => {
    // Calculate the price per item in order
    // according to the walk-in pricing
    ...
    return totalPrice;
}

const onlinePricing = (orders: CustomerOrder): Number => {
    // Calculate the price per item in order
    // according to the online pricing
    ...
    return totalPrice;      
}


const getTotalPrice =
(pricingStrategy: (CustomerOrder) => Number,
orders: CustomerOrders): Number => {
    return pricingStrategy(orders);
}

...
let pricing;
switch(customer.type) {
    case "walkIn":
      pricing = walkInPricing;
      break;
    case "online":
      pricing = onlinePricing;
      break;
    default:
      throw new IllegalCustomerType("...");
}
getTotalPrice(pricing, orders);

As you can see, we simply substitute the Strategy interface with the getTotalPrice function which consumes the pricing algorithm specified as a parameter and returns us the price for the given function.

This structure allows us to leverage off the same extensibility and encapsulated design that the pattern gives us in the OOP approach! With lesser OOP specific syntax, the code is also shorter and more understandable, which more complex implementations can benefit from.

What's next

This post is Part 1 of a series on utilizing Design Patterns in the context of Functional Programming. If you are interested in learning more about design patterns implementing in the Functional Programming paradigm, stay tuned for more on my DEV page.