DEV Community: Christian Kreiling

Polymorphism: Elixir vs. Java

Christian Kreiling — Sun, 08 Sep 2019 16:35:12 +0000

Introduction

This post seeks to enhance the understanding of Elixir protocols by comparing them to class hierarchies in Java. Though the two languages are much different, they share a common, powerful feature: Polymorphism.

When you first start learning Elixir, the first thing people say you have to do is wrap your head around Functional Programming (FP). This might mean kicking some old habits that have formed from using traditionally object-oriented languages such as Java and Python, and thinking slightly differently when you're writing code and designing software.

Though every Elixir dev will tell you how great FP is and why they love it, a lesser-known feature to beginner Elixir devs is its support for polymorphism through Protocols.

Polymorphism is a concept that is at the core of object-oriented programming, making it a feature that seems contrary to the core of the Elixir language. We'll see why it's useful, and compare them to familiar, foundational features in Java.

Who is this article for?

This article introduces the use of protocols in Elixir to achieve polymorphic functionality. If you've never heard of Elixir before, be sure to check out the Elixir website for more details on this exciting young language.

If you're at all familiar with Object Oriented Programming (OOP) in Java, this post will help to draw similarities between Java class hierarchies and Elixir protocols.

What is polymorphism?

Polymorphism is when our program dispatches to functions or methods based on the given data's type, or class.

For example, in Java we have the ability to define an interface, which only contains method definitions that outline some functionality. We then provide the implementations for an interface's method definitions when we define a class which implements that interface.

If a method's signature accepts an instance of an interface and calls a method on that instance, then at runtime, Java decides which method definition to dispatch to based on the underlying implementation class.

This allows us to decouple our code by not tying our implementation of one module, to the implementation of another module.

Java class hierarchies

Let's use a simple example here. Americans measure their height in inches, whereas the rest of the world uses centimetres. I'm sure some parts of the world use other units of measurement, but for the sake of simplicity we will stick with that assumption.

Let's define an interface for measuring Americans, or someone from the rest of the world, in either centimetres or inches:

public interface MeasuredPerson {
  double measureInInches();
  double measureInCentimetres();
}

Now we can implement this interface in a couple of classes which represent people from America and the rest of the world:

public class American implements MeasuredPerson {
  private String name;
  private double heightInInches;

  public American(String name, double heightInInches) {
    this.name = name;
    this.heightInInches = heightInInches;
  }

  public double measureInInches() { return heightInInches; }
  public double measureInCentimetres() { return heightInInches * 2.54; }
}

public class RestOfTheWorld implements MeasuredPerson {
  private String name;
  private double heightInCentimetres;

  public American(String name, double heightInCentimetres) {
    this.name = name;
    this.heightInCentimetres = heightInCentimetres;
  }

  public double measureInInches() { return heightInCentimetres * 0.39; }
  public double measureInCentimetres() { return heightInCentimetres; }
}

Now that we have a couple of classes we can use, we can write a method that accepts a MeasuredPerson and prints out their height in inches.

public class Main {
  public static void main(string[] args) {
    American american = new American("John", 72);
    RestOfTheWorld restOfTheWorld = new RestOfTheWorld("Jean", 178);

    printInches(american);
    printInches(restOfTheWorld);
  }

  private void printInches(MeasuredPerson measuredPerson) {
    System.out.println("The person's height is: " + measuredPerson.measureInInches());
  }
}

This code will print out the height in inches of both the American and the person from the rest of the world. The method printInches dispatches the call to measureInInches at runtime based on the underlying type of the given object!

Elixir protocols

Protocols in Elixir allow for us to define similar relationships in our programs. First, we define a protocol, which is a set of function definitions that outline some functionality. We then provide the implementations for a protocol's function definitions when we define an implementation module for an Elixir type.

Elixir types include List, Map, and Keyword, but they can also include custom structs that we define. The following is an example of two Person structs, similar to our Java classes which we defined above:

defmodule Person.American do
  defstruct [:name, :height_in_inches]
end

defmodule Person.RestOfTheWorld do
  defstruct [:name, :height_in_centimetres]
end

Americans measure their height in inches, and the rest of the world measures their height in centimetres. What if we want to measure a person, without worrying about whether they're from America, or somewhere else in the world?

The `defprotocol` keyword

Similar to how we defined an interface in Java, we can define a protocol for measuring the height of a person. The protocol expects a unit of measurement which the user wants to measure a given person with.

defprotocol Person.Height do
  @doc """
  Accepts the person to measure as the first argument, and accepts either
  `:inches` or `:centimetres` as the second argument to indicate 
  which unit of measurement to return.
  """
  def measure(person, unit_of_measurement)
end

Notice that we don't provide a do block for our measure/2 function. The next section will show how we define an implementation for our fresh protocol.

The `defimpl` keyword

The following modules use the defimpl keyword to provide an implementation for our custom person structs:

defimpl Person.Height, for: Person.American do
  def measure(%Person.American{height_in_inches: height_in_inches}, :inches) do
    height_in_inches
  end

  def measure(%Person.American{height_in_inches: height_in_inches}, :centimetres) do
    height_in_inches * 2.54
  end
end

defimpl Person.Height, for: Person.RestOfTheWorld do
  def measure(%Person.RestOfTheWorld{height_in_centimetres: height_in_centimetres}, :inches) do
    height_in_centimetres * 0.39
  end

  def measure(%Person.RestOfTheWorld{height_in_centimetres: height_in_centimetres}, :centimetres) do
    height_in_centimetres
  end
end

defimpl takes a protocol module (defined using defprotocol), and the module mapping to the type that we want to provide an implementation for. The first argument to our measure/2 functions defined in our implementation modules is therefore a struct of that type.

There is a key difference from our Java implementation: instead of implementing the behavior inside the Person.American and Person.RestOfTheWorld modules, we implement the behavior in a separate module. Since structs themselves can't have behavior (i.e. you can't call american.measure(:centimetres)), the struct must be passed to the function instead; see below for how we do this.

Tying it all together

Now that we've defined a couple of implementation modules for our Person.American and Person.RestOfTheWorld structs, we can call the Person.Height.measure/2 function to measure the given person in our preferred unit of measurement!

%Person.American{name: "John", height_in_inches: 72}
|> Person.Height.measure(:centimetres)
|> IO.inspect()
# 182.88

%Person.RestOfTheWorld{name: "Jean", height_in_centimetres: 178}
|> Person.Height.measure(:inches)
|> IO.inspect()
# 70.0787

The power of protocols

We've used a simple example here to show how we can create our own protocols. But what's the big deal?

Using protocols is powerful because we can define a single interface with well-defined behavior once, and then implement that behavior elsewhere based on our custom struct.

A big advantage which Elixir protocols have over Java class hierarchies is that we can supply implementations of our own protocols for structs from external libraries. In Java, you'd have to edit the source code of other libraries to implement your custom interface. But in Elixir, all we have to do is provide an implementation for a type (struct), regardless of what library/framework provides that type!

A familiar example

In Elixir, we use the Enum module for traversing lists and maps. Anything we pass as the first argument to the functions in the Enum module must have an implementation for the Enumerable protocol! To read more about this check out the Enumerable docs.

Resources

I'd like to provide some additional resources for learning about Elixir Protocols, so you can continue to explore this OOP concept in a traditionally functional language.

Elixir protocols: the introduction to Elixir protocols on the official Elixir lang website.
Elixir Protocol docs: if you're looking for a deeper dive into how protocols work, this is a good place to start. The Elixir docs are written so well that usually I don't look elsewhere.
Programming Elixir >= 1.6: this book is one of the best tools in my arsenal. I couldn't recommend a better book for beginners and experts alike. I use it as reference all of the time.

I wrote this post for those of us that are familiar with the power of OOP, and to showcase an awesome feature in Elixir that feels right at home for anyone familiar with OOP in Java. Thanks for reading!

Single-source-of-truth routing with GatsbyJS static site generator

Christian Kreiling — Mon, 22 Oct 2018 15:22:27 +0000

The beauty of Gatsby

Gatsby is a beautiful tool for building static sites with modern tools.
It leverages the component architecture of React, and cleverly server-side renders
your site at build-time to generate a static website, ready to go.

All you have to do is export a component from any *.js file in the auto-generated src/pages directory in your project, and it'll create a route when it builds your static website based on the name of that file. That alone is enough
to get a static website off the ground in no time!

Gatsby also supplies a slew of build hooks you can write functions for in order to generate pages, GraphQL nodes, wrap your app with a component, and just about everything in between.

The problem with Gatsby

When creating a website, it's nice to have a single source of truth when creating
routes. Endpoints are the backbone of the internet, and managing them in a
quickly growing application can become tiresome if there isn't a single module that you can point to for truth.

With regards to routing, Gatsby's biggest strength is also its biggest weakness;
the src/pages directory, as magical as it sounds, supplies no means of referencing the paths that are built based on the filenames. That means in order to link to another page in your site, you have to hard code the reference as a string to another page. Gross!

My solution

If you want to just peak at the final solution, here's a link to the repo.

We're going to use Gatsby's createPages build hook in order to create our routes. Gatsby uses Redux under the hood in order to maintain state, and passes bound action creators to all of its build hooks. We'll use the createPage action creator within the creatPages build hook. I'll walk you through every step, starting with generating a fresh static site with Gatsby's build tool.

If you haven't installed it, run the following in your command line:

npm install -g gatsby

Generate the website

This is the easy part! To create a new Gatsby site in the gatsby-routing directory, run the following command:

gatsby new gatsby-routing

Setting up the routes

Let's create a directory src/routes, and move index.js and page-2.js
from src/pages to the new routes directory. Rename index.js to home.js.
After that, create a new file called index.js, and put the following code
inside it:

// src/routes/index.js
const path = require('path')

const routes = {
  home: {
    path: '/',
    component: path.resolve(__dirname, 'home.js')
  },
  page2: {
    path: '/page-2',
    component: path.resolve(__dirname, 'page-2.js')
  }
}

export { routes }

We have to use Node APIs like path instead of ES6 import because we'll be
requiring this file in Gatsby's gatsby-node.js file. Let's set these routes up
so they're ready to render - open gatsby-node.js and place the following
code inside.

const { routes } = require('./src/routes')

exports.createPages = ({ actions }) => {
  const { createPage } = actions
  Object.keys(routes).forEach(route => createPage(routes[route]))
}

So in createPages we use the createPage action creator to make new pages,
using the objects from the routes object that we imported. createPage takes
an object with a path string and a React component to render for that path,
and an optional context that you can pass to the React component as props.

Run gatsby develop from the root of your project to see the effects!

Converting links to reference our routes

If you look inside the components in the src/routes directory, you'll notice
we're still hard-coding paths in our links. Let's fix that now!

First, let's unnest our routes and create an object with the same keys as our
routes, but with just the path strings as their values. Your src/routes/index.js
should now look like this:

// src/routes/index.js
const path = require('path')

const routes = {
  home: {
    path: '/',
    component: path.resolve(__dirname, 'home.js')
  },
  page2: {
    path: '/page-2',
    component: path.resolve(__dirname, 'page-2.js')
  }
}

// Same keys as 'routes', but the value is only the path.
const paths = Object.keys(routes).reduce((acc, route) => {
  acc[route] = routes[route].path
  return acc
}, {})

export { routes, paths }

Now let's import our new paths object, and use it to link around our Gatsby
site!

// src/routes/home.js
import React from 'react'
import { Link } from 'gatsby'

import Layout from '../components/layout'

import { paths } from './'

const IndexPage = () => (
  <Layout>
    <h1>Hi people</h1>
    <p>Welcome to your new Gatsby site.</p>
    <p>Now go build something great.</p>
    <Link to={paths.page2}>Go to page 2</Link>
  </Layout>
)

export default IndexPage


// src/routes/page-2.js
import React from 'react'
import { Link } from 'gatsby'

import Layout from '../components/layout'

import { paths } from './'

const SecondPage = () => (
  <Layout>
    <h1>Hi from the second page</h1>
    <p>Welcome to page 2</p>
    <Link to={paths.home}>Go back to the homepage</Link>
  </Layout>
)

export default SecondPage

And just like that, we're no longer hard-coding our site's paths in any of
our components! Now creating a new route is as easy as creating a new component,
and adding it to src/routes/index.js.

Wrap-up

If you're new to JavaScript, or want to learn React, Gatsby is a great place to
start. I'm in the process of building a large application, and can't afford to
be hard-coding URLs into my app. I hope that this helps someone else that's in
a similar situation!

This is my first official blog post, I'd love some feedback :)