Difference between revisions of "API Design"

Revision as of 08:15, 21 January 2007

This is really just a miscellaneous collection of thoughts and links right now, not a full fledged article on API design.

1

Casey Muratori gave a good talk at Game|Tech on Designing and Evaluating Reusable Components, which was really a talk on API design.

Here's the executive summary:

Granularity - A or BC
Flexibility vs. simplicity
Redundancy - A or B
Convenience vs. orthgonality
Coupling - A implies B
Less is always better

Retention - A equals B
Synchronization vs. automation
Flow Control - A invokes B
More game control is always better

2

A great insight on API and language design comes from Larry Wall, the designer of Perl, but I first heard about it from Jon Blow in this article. You want your language or API to be diagonal, not orthogonal like people are used to thinking. If you want to go from one place to another, you want to travel the shortest distance, not have to take the Manhattan path.

@@ Line 1: / Line 1: @@
 This is really just a miscellaneous collection of thoughts and links right now, not a full fledged article on API design.
-===Casey===
+===1===
 [http://mollyrocket.com Casey Muratori] gave a good talk at [http://game-tech.com/ Game|Tech] on
 [https://mollyrocket.com/forums/viewtopic.php?t=215 Designing and Evaluating Reusable Components], which was really a talk on API design.
@@ Line 15: / Line 15: @@
 </td></tr></table>
-===Jon===
+===2===
 A great insight on API and language design comes from Larry Wall, the designer of Perl, but I first heard about it from [http://number-none.com/blow Jon Blow] in [http://number-none.com/product/Lerp,%20Part%201/index.html this article].  You want your language or API to be ''diagonal'', not ''orthogonal'' like people are used to thinking.  If you want to go from one place to another, you want to travel the shortest distance, not have to take the Manhattan path.