API design, hjemmearbejde
Så er ferien forbi, hiv havemøblerne ud af øregangene, sæt jer og hør efter!
API, Application Programming Interfaces, er mursten og mørtel for programmering.
Desværre.
Hvor byggefaget har vidreudviklet sig og anvender forspændt beton og selvbærende konstruktioner, så slås vi i computerbranchen stadig med håndstrøgne sten af tilfældigt ler og klumpet mørtel.
Er helt simpelt eksempel: Posix Threads API har ikke en "assert mutex (not) held" facilitet.
Her er tre artikler, to gamle af undertegnede og en frisk af Michi Henning om API design:
Userland/Kernel Interfaces (Daemonnews 2003/05)
Complex and extensible configuration interfaces (Daemonnews 2003/08)
API: Design Matters (ACM Queue Magazine 2008/08)
Når I har læst dem, skal i besvare følgende spørgsmål:
1: Hvorfor skal der stadig 5-7 funktionskald til at åbne en TCP forbindelse til en server hvis man bruger C ?
2: Hvor er API'et til WLAN netværk defineret ?
3: Definer et kriterie for hvad der er et API og hvad der ikke er.
phk
Om Poul-Henning KampPoul-Henning er selvstændig systemprogrammør, kernekoder, Varnish-forfatter, data-arkæolog og brokkehoved uden særlig portefølje.
Follow @bsdphkKommentarer (8)
I mange tilfælde kan et domænespecifikt sprog (DSL) være et godt alternativ til en API. Med et DSL får du dels en mere naturlig syntaks (og undgår dermed de 5-7 kald for at åbne en TCP-forbindelse), og du kan få statisk check af konsistens o.lign.
Med et API presses alt ned i den prokrustiske seng, der hedder metode- eller funktionskald, og man skal ofte angive parametre som tekststrenge eller heltal, hvorved man mister både statisk check og semantisk gennemskuelighed. Og man kan sjældent opnå de optimeringer, som global oversættelse af et DSL kan, da oversætteren ikke kender betydningen af de enkelte kald og deres interaktion.
Se for eksempel på forskellen på at programmere en søgning i et XML-dokument med DOM (et API) eller med XQuery (et DSL).
-
0 -
0
Torben. Jeg forstår dine ord men jeg forstår ikke hvad du mener. Er det DSL ikke lidt overkill for at åbne en TCP forbindelse? For ikke at tale om problemet med at huske at få den lukket igen.
Personligt foretrækker jeg at indkaplse den slags på lignende vis som http://www.research.att.com/~bs/bs_faq2.html#finally.
Det er da simpelt og til at forstå. Bare fordi man har et gammelt API som ikke kan ændres, behøver det jo ikke betyde at man skal blive ved med at benytte det. Kan det ikke gøres lidt bedre? Jo det tror jeg nok det kan.
/mrj
-
0
-
0
Nu lige for at tage brownie-point-#1 fra din artikel, så peger begge links i denne artikel på den samme ;)
Fordi TCP forbindelser skal bruge 5-7 kald i et givent API, så er der jo ikke noget der forhindrer dig i at abstrahere det væk i et "højere" API. Der er sikkert nogen som vil kunne bruge begge abstrationsniveauer alt efter hvad man lige sidder med.
-
0
-
0
Joshua Bloch har skrevet en hel del kloge ord om API'er. En et-times præsentation om emnet fra januar i år kan findes på Google Video:
http://video.google.com/videoplay?docid=-3733345136856180693
-
0
-
0
Linket er rettet nu (når v2's cache timer ud ?)
Og du har helt ret søren, jeg kan sagtens abstrahere de 5-7 systemkald ind i et højere API selv, men hvorfor skal alle programmører der skal bruge en tcp-forbindelse i et C-program gøre det selv ?
Burde vi ikke, efter 37 år, have et sådant højrere API i libc ?
Poul-Henning
-
0
-
0
> Hvor byggefaget har vidreudviklet sig og anvender forspændt beton og selvbærende konstruktioner, så slås vi i computerbranchen stadig med håndstrøgne sten af tilfældigt ler og klumpet mørtel.
Vi nørder har jo også miljøer såsom Java og .NET, hvor man ikke bruger 5-7 kald på at åbne en forbindelse. Gad vide om ikke tabet/begrænsningerne, ved at arbejde i sådanne miljøer, svarer nogenlunde til det man oplever ved skiftet fra mursten til forspændt beton?
-
0
-
0
Av, jeg havde ikke fået læst dine links ordenligt igennem. Min forrige kommentar faldt vist ligesom lidt til jorden her :-)
-
0
-
0
Tilføj kommentar
