2021-03-14 12:01:23 +00:00
|
|
|
#+TITLE: service-pattern
|
|
|
|
#+Author: Yann Esposito
|
|
|
|
#+Date: [2021-03-14]
|
|
|
|
|
|
|
|
- tags :: programming
|
|
|
|
- source ::
|
2021-03-14 12:03:39 +00:00
|
|
|
|
|
|
|
The question about code structure and organization is one of the most
|
|
|
|
prolific one.
|
|
|
|
The problem are always the same.
|
|
|
|
|
|
|
|
Here I will talk about one possible solution in this huge design space.
|
2021-03-14 12:05:19 +00:00
|
|
|
First of all, I will focus on a functional programming pattern.
|
2021-03-14 12:06:46 +00:00
|
|
|
But I think the lessons could be extended to any generic programming
|
|
|
|
language.
|
|
|
|
|
|
|
|
Before explaining the pattern I would like to take the time to provide a
|
|
|
|
few distinctions between different programming language patterns.
|
2021-03-14 12:07:52 +00:00
|
|
|
Quite often, one fundamental question very important when choosing a
|
|
|
|
pattern for your code is about find the the correct level of the pattern.
|
|
|
|
|
|
|
|
There are a tower of patterns and meta-patterns.
|
|
|
|
For example in imperative programming not using =goto= statement was
|
|
|
|
considered as a programming pattern.
|
2021-03-14 12:09:02 +00:00
|
|
|
Once that idea was accepted there were work done on /Object Oriented
|
|
|
|
Programming/.
|
2021-03-14 12:10:59 +00:00
|
|
|
And OOP was considered as a programming language pattern.
|
|
|
|
But OOP while already providing quite a constraint on your code
|
|
|
|
architecture was enough not sufficient.
|
|
|
|
OOP alone leave a lot of room in the design space.
|
|
|
|
Thus we've seen numerous "OOP Design Pattern".
|
|
|
|
That used the underlying OOP paradigm as a base and constructed
|
|
|
|
abstractions over it.
|
2021-03-14 12:12:43 +00:00
|
|
|
|
|
|
|
Even with all those Design Pattern it was up to the programmer to decide
|
|
|
|
which one applies or not.
|
|
|
|
Quite often there is not a single path easy to detect correct design
|
|
|
|
pattern.
|
|
|
|
Mainly the very hard part in programming is choosing the right abstraction.
|
2021-03-14 12:15:32 +00:00
|
|
|
|
|
|
|
There are other code structures to choose from.
|
|
|
|
In functional programming there are FRP.
|
|
|
|
Here also there are stories about how design pattern once choosen make a
|
|
|
|
natural evolution toward meta-design-patterns.
|
|
|
|
Mainly design pattern that rely on a lower level design pattern.
|
|
|
|
|
|
|
|
If you take the story behind Elm Architecture you can see it.
|
|
|
|
At first there were FRP.
|
|
|
|
Elm removed the behaviour from FRP to only deal with events to simplify the
|
|
|
|
model.
|
2021-03-14 12:16:47 +00:00
|
|
|
But with FRP the author clearly though it was a good-enough design pattern.
|
|
|
|
But the design space was a bit too big.
|
|
|
|
So it was difficult to take the right decision.
|
|
|
|
So a natural meta-pattern appeared.
|
2021-03-14 12:19:53 +00:00
|
|
|
It is [[https://guide.elm-lang.org/architecture/][/Elm Architecture/]].
|
|
|
|
So while Elm imposed so structure of your program using static types to
|
|
|
|
prevent common coding mistakes and enforce a specific code structure.
|
|
|
|
Elm did not constrain the file organisation, the number of buffers to
|
|
|
|
send/receive events, the way they should talk/listen between each other.
|