Conceptual surface
From APIDesign
(New page: The term conceptual surface has been coined by Tim Boudreau during our talks about API Design. It describes the amount of concepts one needs to understand when dealing with an ...) |
|||
| Line 1: | Line 1: | ||
| - | The term [[conceptual surface]] has been coined by [[Tim Boudreau]] during our talks about [[API Design]]. It describes the amount of concepts one needs to understand when dealing with an [[API]]. | + | The term [[conceptual surface]] has been coined by [[Tim Boudreau]] during our talks about [[API Design]]. It describes the amount of concepts one needs to understand when dealing with an [[API]]. [[Conceptual surface]] metric is a very way to measure '''complexity''' of an [[API]]. |
One common advice when it comes to separating [[APIvsSPI]] is to make sure the classes in the [[ClientAPI]] part (e.g. the [[conceptual surface]] of the [[API]]) doesn't reference the service provider part ([[SPI]]). This advice optimizes for the common case where the number of people making calls into the [[API]] (e.g. using the [[ClientAPI]] part) is an order of magnitude bigger than those providing implementation of services (e.g. [[ProviderSPI]]). Also the service provider part is often more complicated and could scary the [[cluelessness]] out of newcomers. | One common advice when it comes to separating [[APIvsSPI]] is to make sure the classes in the [[ClientAPI]] part (e.g. the [[conceptual surface]] of the [[API]]) doesn't reference the service provider part ([[SPI]]). This advice optimizes for the common case where the number of people making calls into the [[API]] (e.g. using the [[ClientAPI]] part) is an order of magnitude bigger than those providing implementation of services (e.g. [[ProviderSPI]]). Also the service provider part is often more complicated and could scary the [[cluelessness]] out of newcomers. | ||
[[Category:APIDesignPatterns:Clarity]] [[Category:APIDesignPatterns:Meta]] | [[Category:APIDesignPatterns:Clarity]] [[Category:APIDesignPatterns:Meta]] | ||
Revision as of 08:06, 1 February 2018
The term conceptual surface has been coined by Tim Boudreau during our talks about API Design. It describes the amount of concepts one needs to understand when dealing with an API. Conceptual surface metric is a very way to measure complexity of an API.
One common advice when it comes to separating APIvsSPI is to make sure the classes in the ClientAPI part (e.g. the conceptual surface of the API) doesn't reference the service provider part (SPI). This advice optimizes for the common case where the number of people making calls into the API (e.g. using the ClientAPI part) is an order of magnitude bigger than those providing implementation of services (e.g. ProviderSPI). Also the service provider part is often more complicated and could scary the cluelessness out of newcomers.
Follow
