'. '

ClientAPI

From APIDesign

(Difference between revisions)
Jump to: navigation, search
m (APIDesignPatterns:ClientAPI moved to ClientAPI: Shorter names for use with categories)
Line 1: Line 1:
-
There is a difference between [[APIDesignPatterns:ClientAPI]] and [[APIDesignPatterns:ProviderAPI]] evolution rules. As soon as you publish an API targeted for others to call, you, as publisher of your library, want to have the freedom to satisfy additional requirements of users of your library. What additional requirements can you expect? In case the only use of your API is that it can be called, then the common requirement is going to be a request to expose more methods and to allow the users to call more functionality.
+
There is a difference between [[ClientAPI]] and [[APIDesignPatterns:ProviderAPI]] evolution rules. As soon as you publish an API targeted for others to call, you, as publisher of your library, want to have the freedom to satisfy additional requirements of users of your library. What additional requirements can you expect? In case the only use of your API is that it can be called, then the common requirement is going to be a request to expose more methods and to allow the users to call more functionality.
-
What is the most suitable coding construct in [[Java]] to support [[BackwardCompatibility|backward compatible]] additions of new methods? The most safe one is a final class. As such it suggested to expose only final classes to users of [[APIDesignPatterns:ClientAPI]].
+
What is the most suitable coding construct in [[Java]] to support [[BackwardCompatibility|backward compatible]] additions of new methods? The most safe one is a final class. As such it suggested to expose only final classes to users of [[ClientAPI]].
 +
 
 +
 
 +
[[Category:APIDesignPatterns]]
 +
[[Category:APIDesignPatterns:Evolution]]

Revision as of 12:32, 15 November 2008

There is a difference between ClientAPI and APIDesignPatterns:ProviderAPI evolution rules. As soon as you publish an API targeted for others to call, you, as publisher of your library, want to have the freedom to satisfy additional requirements of users of your library. What additional requirements can you expect? In case the only use of your API is that it can be called, then the common requirement is going to be a request to expose more methods and to allow the users to call more functionality.

What is the most suitable coding construct in Java to support backward compatible additions of new methods? The most safe one is a final class. As such it suggested to expose only final classes to users of ClientAPI.

Personal tools
buy