Runtime Aspects of APIs

From APIDesign

(Difference between revisions)
Jump to: navigation, search
(New page: API Signatures are definitely the only API we shall be interested in.)
Line 1: Line 1:
-
API Signatures are definitely the only API we shall be interested in.
+
== Have You Ever Wondered...? ==
 +
 
 +
Did you ever tried to find the border line between the API and its implementation? Is javadoc API? I guess, so. Do names of public classes and methods belong into the API? Are the checks for incorrect parameter types throwing ''IllegalArgumentException'' part of API? Are ''NullPointerException''s thrown from inside of the API method bodies part of API? And what about the order of callbacks to client code, order of event delivery, identity of threads the callbacks happen in? Is speed of method execution or the amount of allocated memory important for API users? I guess it may be, at least in the [[wikipedia::Real-time_computing|real-time]] world. But then: Where is the border between API and its implementation!? The [[Runtime Aspects of APIs|chapter 11]] shows why the APIs do not end at method and class signatures. It explains why these ''runtime'' APIs are important and what needs to be done to evolve them in the right way - evolve them compatibly. The [[Runtime Aspects of APIs|chapter 11]] does not reveal the holy grail, but it presents a technique proven to work, capable to ensure runtime backward compatibility.

Revision as of 20:51, 13 August 2008

Have You Ever Wondered...?

Did you ever tried to find the border line between the API and its implementation? Is javadoc API? I guess, so. Do names of public classes and methods belong into the API? Are the checks for incorrect parameter types throwing IllegalArgumentException part of API? Are NullPointerExceptions thrown from inside of the API method bodies part of API? And what about the order of callbacks to client code, order of event delivery, identity of threads the callbacks happen in? Is speed of method execution or the amount of allocated memory important for API users? I guess it may be, at least in the real-time world. But then: Where is the border between API and its implementation!? The chapter 11 shows why the APIs do not end at method and class signatures. It explains why these runtime APIs are important and what needs to be done to evolve them in the right way - evolve them compatibly. The chapter 11 does not reveal the holy grail, but it presents a technique proven to work, capable to ensure runtime backward compatibility.

Personal tools
buy