39 lines
1.5 KiB
Org Mode
39 lines
1.5 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.
|