←Older revision | Revision as of 08:41, 1 February 2018 | ||
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]]. [[Conceptual surface]] metric is a very way to measure '''complexity''' of 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 useful 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. [[ProviderAPI]]). 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. [[ProviderAPI]]). 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]] |