ProviderAPI
From APIDesign
(Difference between revisions)
| Line 1: | Line 1: | ||
| - | Rules for extending [[APIDesignPatterns:ProviderAPI|API designed for implementors]] are very different to those for [[APIDesignPatterns:ClientAPI|API that can only be called]]. In case you have a provider | + | Rules for extending [[APIDesignPatterns:ProviderAPI|API designed for implementors]] are very different to those for [[APIDesignPatterns:ClientAPI|API that can only be called]]. In case you have a provider implementing your interface, the obvious expectation of that person seems to be that the once provided implementation, written and potentially compiled once in a time, will continue to work forever. |
The easiest way to break this promise is to add new non-implemented methods into the type. As such do not add new methods to ''interface''s or ''abstract classes'' implemented by some [[APIDesignPatterns:ProviderAPI|providers]]. This immediately breaks the promise of source [[BackwardCompatibility]]. | The easiest way to break this promise is to add new non-implemented methods into the type. As such do not add new methods to ''interface''s or ''abstract classes'' implemented by some [[APIDesignPatterns:ProviderAPI|providers]]. This immediately breaks the promise of source [[BackwardCompatibility]]. | ||
Revision as of 07:08, 23 October 2008
Rules for extending API designed for implementors are very different to those for API that can only be called. In case you have a provider implementing your interface, the obvious expectation of that person seems to be that the once provided implementation, written and potentially compiled once in a time, will continue to work forever.
The easiest way to break this promise is to add new non-implemented methods into the type. As such do not add new methods to interfaces or abstract classes implemented by some providers. This immediately breaks the promise of source BackwardCompatibility.
TBD: Fragile methods additions
TBD: Interfaces and clear definition of a version
Follow
