87 lines
3.9 KiB
Org Mode
87 lines
3.9 KiB
Org Mode
#+TITLE: service-pattern
|
|
#+Author: Yann Esposito
|
|
#+Date: [2021-03-14]
|
|
|
|
- tags :: programming
|
|
- source ::
|
|
|
|
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.
|
|
First of all, I will focus on a functional programming pattern.
|
|
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.
|
|
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.
|
|
Once that idea was accepted there were work done on /Object Oriented
|
|
Programming/.
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
|
|
So Elm Architecture is a non enforced meta structure for your code
|
|
application.
|
|
Unlike the underlying layer of architecture.
|
|
But what Elm Architecture provide is a higher level architecture that will
|
|
help your program to "scale" and whose natural organisation is easy to
|
|
understand.
|
|
|
|
So Elm Architecture is more of a proposal that will potentially have
|
|
drawback.
|
|
Typically, if you change the organisation of your views, it could cost a
|
|
lot of change in your code.
|
|
But most of the time this is acceptable and preferable.
|
|
Because, the Elm Architecture is simple to understand and quite often this
|
|
is not such a big deal.
|
|
Not using the Elm Architecture paradigm put you at risk to end up in a
|
|
spaghetti code hell.
|
|
But of course there is a tension between code size/DRYness and easy to
|
|
understand code organisation/architecture.
|
|
|
|
If you have a short code base, DRYness could probably be preferable.
|
|
Because a bit of disorganisation and shortcuts will not be unbearable.
|
|
But as the size of your code grow, it will become more and more prevalent
|
|
that a strict code organisation with perhaps more repetitions and a bit
|
|
more conventions implying more lines of code become preferable because it
|
|
minimise the risk of surprise between different part of the code.
|
|
Clearly, Elm Architure is selling compactness of your code for an easier to
|
|
read, discover and understand overall code architecture.
|