books/The-API-Book
1
0
Fork 0
mirror of https://github.com/twirl/The-API-Book.git synced 2025-02-22 18:42:09 +02:00
Code Issues Releases Activity

style fix

Browse Source
This commit is contained in:
Sergey Konstantinov 2023-03-04 11:39:36 +02:00 committed by GitHub
parent c7a5b1aedb
commit 9ea53dade3
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
src/en/clean-copy/02-Section I. The API Design/03.md
View File

@ -118,8 +118,8 @@ Abstraction levels separation should go in three directions:
The more is the distance between programmable contexts our API connects, the deeper is the hierarchy of the entities we are to develop.
In our example with coffee readiness detection, we clearly face the situation when we need an interim abstraction level:
* from one side, an “order” should not store the data regarding coffee machine sensors;
* on the other side, a coffee machine should not store the data regarding order properties (and its API probably doesn't provide such functionality).
* on one hand, an “order” should not store the data regarding coffee machine sensors;
* on the other hand, a coffee machine should not store the data regarding order properties (and its API probably doesn't provide such functionality).
A naïve approach to this situation is to design an interim abstraction level as a “connecting link,” which reformulates tasks from one abstraction level into another. For example, introduce a `task` entity like that: