Better design pattern for creating a polymorphic API

Thinking out loud, I suppose behaviours could be a solution? If I’m willing to accept that passing the right parser as an argument is better than having a polymorphic parse/2 function.

I could declare parse/2 as a behaviour and implement it in each module (Parsers.User, and Parsers.AccessKey). I would then pass the right parser as an argument.

  def parse({:ok, %{body: xml, status_code: status} = resp}, action) when status in 200..299 do
    parsed_body = dispatch(xml, action)
    {:ok, %{resp | body: parsed_body}}
  end

Still, it would be nice to just call parse/2 and have the API figure out which module to call.

Have you considered:

  # in some module ..

  def list_users, do: {User,:list_users}
  def create_user, do: {User,:create_user}
  def list_access_keys, do: {AccessKey, :list_access_keys}
  def get_access_key_last_used, do: {AccessKey, :get_access_key_last_used}

  # somewhere else ...

  def parse({:ok, %{body: xml, status_code: status} = resp}, {mod,fun}) when status in 200..299 do
    parsed_body = apply(mod, fun, [xml])
    {:ok, %{resp | body: parsed_body}}
  end

I don’t control the calling code. ExAws does that part. It just calls the parser I provide as an argument.

Here’s how I currently send the parser:

  def list_users(opts \\ []) do
    :list_users
    |> to_params(opts)
    |> to_op(parser: &Parser.parse/2)
  end

So it’s easy enough to replace |> to_op(parser: &Parser.parse/2) with |> to_op(parser: &Parsers.User.parse/2). But I was looking for a better way.

I do this kind of things with adapter pattern where I set the adapter in config, have a behavior that is an interface for adapters and few adapter modules (some call API, some use ETS some just serve hardcoced responses). A “public” wrapper module can then call configured adapter and depending on the env different implementations can be used, the context (that is the only really public module) can delegate to that wrapper module then.

The best way in Elixir I could see is a mix of your original approach, and behaviours.

1. Behaviour:

defmodule ExAws.Iam.Consumer do
  @callback consume_response(String.t, String.t) :: any # (xml, action)
end

2. Implementers:

defmodule User do
  @behaviour ExAws.Iam.Consumer
  def consume_response(xml, action), do: #...
end

3. Refactor dispatch to use router functions like so:

defp consumer(action) when action in @user_actions, do: User
defp consumer(action) when action in @access_key_actions, do: AccessKey

#...

defp dispatch(xml, action), do: consumer(action).consume_response(xml, action)

Code is not tested. But IMO this brings you close enough to some practical polymorphism while remaining terse enough.

(Another alternative would be to have a big module where you match on all possible combos but I don’t think it would be an improvement over your current approach – except maybe for having less source files.)

def SomeModule do

  @action_parsers %{
    "ListUsers" => User,
    "CreateUser" => User,
    "ListAccessKeys" => AccessKey,
    "GetAccessKeyLastUsed" => AccessKey
  }
 
  def parse({:ok, %{body: xml, status_code: status} = resp}, action) when status in 200..299 do
    with {:ok, mod} <- Map.fetch(@action_parsers, action) do
       parsed_body = apply(mod, :parse, [xml, action])
       {:ok, %{resp | body: parsed_body}}
    else
      _ ->
        # BOOM
    end
  end

end

But as it is you’ll probably be best off by pursuing the behaviour angle further if just to capture the implementation commonalities between your various parsers.

That’s essentially what I had before I went into a refactoring rabbit hole. It might just be simpler to pass the parser in the public function. For example:

  def list_users(opts \\ []) do
    :list_users
    |> to_params(opts)
    |> to_op(parser: &Parsers.User.parse/2)
  end

  def list_access_keys(opts \\ []) do
    :list_access_keys
    |> to_params(opts)
    |> to_op(parser: &Parsers.AccessKey.parse/2)
  end

That’s pretty cool, but it sacrifices explicitness especially as the codebase gets bigger (my current approach also sacrifices explicitness).

Valid reservation. I just feel we can’t go all the way explicit if we need polymorphism though.

As an extra step I would recommend you just make a separate configuration file and just use that in order not to have too much routing logic hardcoded in a module (where other team members might have trouble finding it or it will become hard to maintain as you pointed out).

If you opt for that you should definitely put that string_action->module map that @peerreynders suggested into that config.

I understand the nagging feeling of “it just doesn’t feel right” but don’t get stuck into paralysis analysis. Truth is, functional languages are not ideal when polymorphism is involved and that’s okay because it’s not their main focus. But behaviours and map routers get you close enough, and it’s not like the OOP languages don’t do the same anyway!

IMO just go for the minimal maintenance approach and move on. Even if the code is a bit more. Important part is to be able to add/remove consumers in a minute.

In some contexts “passing a function” can be seen as the functional equivalent of OO’s strategy pattern.