A better Module interaction pattern?

CharlesO

I’m looking to improve this pattern.
It is a pattern I use in a lot of my projects.

defmodule Handler do
    def handle_request(data) do
        response = apply(@some_module_from_config, :parse, [data])

        # do_something_with_response(response)
        ...
    end
end

I then have customer specific implementations of :parse in separate modules, for example

defmodule CustomerA do
    def parse(data) do
        # specific parsing of this data for Customer-A
    end
end

defmodule CustomerB do
    def parse(data) do
         # specific parsing of this data for Customer-B
    end
end

This works, but can it be improved?

Is there a benefit for example to have a @behaviour in Handler which defines :parse and other functions

Then each Customer module no implements use Handler

Please are their better patterns for doing this?

Thanks.

14 comments

#behaviours #learning-elixir

0 687 14

2024-10-14 14:49:42 UTC

Showing Posts 14 to 5

Show Best Posts
Show All (oldest first)
Show All (newest first)

D4no0

You can’t, the module that defines behavior whole point is to make sure that you are implementing the required functions, it’s up to you how you call them afterwards.

You can either use the pattern you are already using with apply/3 or you can call directly the function, as module names are just plain atoms:

my_modules = [CustomerA, CustomerB]
for module <- my_modules do
  module.parse(data)
end

You could add some compile-time checks to ensure that the module you are calling has the behavior declared, but I don’t see a lot of value from that.

Post #14

CharlesO

Please how do we get the return value from the customer module back to the behavior module?

For example, say CustomerA implements parse/1, how can that result be used in ParseBehavior module?

Post #13

D4no0

Nope, all you need is something like this:

defmodule ParseBehavior do
  # Obviously replace any with your data types
  @callback parse(data :: any) :: any
end

defmodule CustomerA do
  @behaviour ParseBehavior 
end

If you don’t implement the specified callbacks you will get a compilation warning.

You can also have the variant with the default implementation:

defmodule ParseBehavior do
  @callback parse(data :: any) :: any

  defmacro __using__(_opts) do
    quote do
      @behaviour ParseBehavior
      
      def parse(data) do
        # This will be the default implementation if not overriden
      end

     defoverridable parse: 1
    end
  end
end

defmodule CustomerA do
   use ParseBehavior

  # This definition will override the default definition
  def parse(data) do
   
  end
end

I wouldn’t recommend using the variant with default implementation unless that is strictly required, as it makes the code harder to read.

Post #12

CharlesO

Please do you know how to setup the behaviors code?

Post #11

thomas642daniel

CharlesO:

I’m looking to improve this pattern.
It is a pattern I use in a lot of my projects.
defmodule Handler do
    def handle_request(data) do
        response = apply(@some_module_from_config, :parse, [data])

        # do_something_with_response(response)
        ...
    end
end
I then have customer specific implementations of :parse in separate modules, for example
defmodule CustomerA do
    def parse(data) do
        # specific parsing of this data for Customer-A
    end
end

defmodule CustomerB do
    def parse(data) do
         # specific parsing of this data for Customer-B
    end
end
This works, but can it be improved?

Is there a benefit for example to have a @behaviour in Handler which defines :parse and other functions

Then each Customer module no implements use Handler

Please are their better patterns for doing this?

Hello,

I love the idea of using behaviors here; it’s like setting a standard for a well-dressed party—everyone knows the dress code!

Post #10

CharlesO

Please can you point to a simple reference implementation?
I’ve not written this type of behavior module before.
I understand it requires macros, yes?

Post #9

al2o3cr

The major benefit is compile-time checking:

if CustomerA says @behaviour Handler but doesn’t supply callbacks with the correct arities, the compiler will complain
(sometimes) Dialyzer will be able to prove that a function’s implementation fails to match the behaviour’s spec

As a side bonus, libraries like mox can use that same behaviour for their definitions.

Post #8

Eiji

Behaviours are well documented, so it would be easiest to check it out. For example here is a quote I was referring to:

If a module adopting a given behaviour doesn’t implement one of the callbacks required by that behaviour, a compile-time warning will be generated.

Source: Behaviours | Typespec reference @ Elixir’s documentation

Post #7