Let’s say we have a Rails application and we want to interact with Twitter. There are probably a few good open source gems already that could help us out with this task.

class HomeController < ApplicationController
  def index
    twitter_client = SomeTwitterClient.connect(ENV['TWITTER_API_KEY'])
    feed = twitter_client.feeds.get("some_user")
    @tweets = feed.tweets
  end
end

Then we just render @tweets in our view. Although our code is not too bad, we’re probably going to run into unwanted issues if we repeat this throughout our application. Consider what happens if we need to update the gem for security fixes, and we discover it also changed the way it connects and interacts with Twitter.

# Notice we call `tweets` directly from the client now
client = Twitter::Client.connect(api_key)
tweets = client.tweets("some_user")

Even a minor change like this will force us to update every piece of code that referenced the old API. Instead, we can write our own application specific interface, with the methods we wish the third-party API had.

module TwitterClient
  def tweets(username)
    client.tweets(username)
  end

  private

  def client
    @client ||= SomeTwitterClient.connect(ENV['TWITTER_API_KEY'])
  end
end

Then in our controller:

def index
  @tweets = TwitterClient.tweets("some_user")
end

Now we isolated the code, so if the third-party library changes we only have to update it in a single place. This is known as the adapter design pattern and allows two otherwise incompatible interfaces to work together.