temper

temper

Design by contract vs defensive data checking in Elixir?

Hello,

I have a question that is probably not limited only to Elixir, but I would like to have your opinion about ‘Elixir’-like, or ‘Elixir way’ solution to the question.

The problem I would like to discuss is the application of the ‘design by contract’ software design principle. In short, when designing a data exchange protocol, both sides of the interface agree on the data types and the boundaries of values used when calling the interface/protocol methods. And in the implementation the caller of the function ensures that the protocol is not violated.
I am coming from a world of languages like C++, Java, Python where design by contract is (at least in theory) applied quite often and to some degree supported by the compilers (C++/Java), Despite this fact, the actual implementations of the protocol are full of checks of the potential protocol violations to ensure that the program will not crash (a classical example is checking for the null value of variables passed as parameters to the method/function calls).

Although I am new to Elixir I feel that this problem can be solved quite elegant in many cases by clever application of proper data structures. But I am curious whether there are some best practices established in Elixir.

I have one concrete example illustrating the problem and the possible (as far as I can see) solutions:

  1. The business logic of my application operates on the data structure representing a week. I encoded it as
defmodule WeeklyTimeDistribution do
  defstruct ~w[mo tu we th fr sa su]a
end
  1. The business logic fills each entry of the WeeklyTimeDistribution with a struct, containing, between other the date of a specific day.

  2. At the end of the processing I store the WeeklyTimeDistribution to external data storage via some boundary module. The module defines a protocol, that operates on the instance of the WeeklyTimeDistribution struct.

  3. The API implementation takes days of the struct and tries to store them. Sometimes however, the storage is not allowed, so I need to exclude some days from storing (I know, it sounds a bit strange, but it is something I cannot change - without going into details: days of the week with dates in the future cannot be stored).

From this point I believe there are two choices:

  1. Setup a ‘contract’ where I set the nil values for the days of the week not to be stored and implement the storage API to skip the days with ‘nil’ values from storing.
  2. Change the data type used between the business logic and storage API by passing a map or a list of only valid days of the week (excluding the days in the future). So the contract says in this case: whatever I pass is “legal” and the boundary shall just store it without any checking.

The 2nd option looks more appealing to me because it makes the boundary (data storage module) simple (no checks for ‘nil’ prior to writing. The storage API just iterates over the passed data structure and stores the data.

Is there a common Elixir design pattern for this problem? Shall the boundary classes be just plain absorbers of the data? Or does some defensive programming still make sense in Elixir? What do you think?

First Post!

ityonemo

ityonemo

I am not a design by contract expert but i feel like 1) is better. It lets you keep strong typing on the week data structure. You can then typespec the week data structure to have it’s fields be nil or Day.t and in your typedoc specify that nil is only valid for future dates (you could probably even write a runtime check for that in your Week consumer).

Most Liked

dimitarvp

dimitarvp

Coding style nitpick: better don’t do this. When working in teams, most people I worked with found it really hard to follow and track in the code.

Better invest in some code snippets software (or VSCode / Emacs / VIM plugin) to just do this:

defstruct [:mo, :tu, :we, :th, :fr, :sa, :su]
temper

temper

Thanks @lud for the advice

temper

temper

Thanks for the tip @dimitarvp. Indeed, the project I am working on is the one-man initiative, and also language exploration exercise for me. So I play with some less popular language constructions to see what works and what not.

Where Next?

Popular in Discussions Top

AstonJ
I’ve just started the Phoenix part of the utterly brilliant online course by @pragdave. On generating the Phoenix app he uses the --no-ec...
New
PragTob
Hey everyone, this has been brewing in my head some time and it came up again while reading Adopting Elixir. GenServers, supervisors et...
New
lorenzo
Hey everone! I created a prototype for my app using Nodejs for the api. But the framework I chose wasnt great (in general theresnt any g...
New
New
nburkley
AWS re:Invent is on at the moment with some interesting announcements. One new feature in particular is the Lambda Runtime API for AWS La...
New
Nvim
Anybody knows a comprehensive comparison of Django and Phoenix, thanks for the help. Where are they similar? Where do they differ the m...
New
mikl
I wanted to capitalize a string, and tried using String.capitalize(). That generally works well, until you try to capitalize a word like...
New

Other popular topics Top

Qqwy
Original source of discussion: This topic on the Pragmatic Programmers’ Functional Web Development with Elixir, OTP, and Phoenix forum. ...
New
jononomo
For some reason my phoenix channels are working for me in my local dev environment, but as soon as I deploy via Docker, I get a 403 error...
New
joeerl
Hello again - after a longish gap I’ve decided I really must dig into Elixir and see what’s been happening here - so I have a few questio...
New
sen
Hi All, I set a environment variables in dev.exs , like below code. when i start server, how can i set the ${enable} value? thanks. d...
New
shijith.k
I am trying to start a new phoenix project with elixir 1.9, but mix phx.new does not work. It says that ** (Mix) The task "phx.new" could...
New
dblack
I’ve got an issue with an app and I’ve no idea of how to troubleshoot it. I’m hoping someone here might have seen something similar. I p...
New

We're in Beta

About us Mission Statement