ProviderAPI
From APIDesign
(Difference between revisions)
| Line 1: | Line 1: | ||
| - | Rules for extending [[ | + | Rules for extending [[ProviderAPI|API designed for implementors]] are very different to those for [[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 [[ | + | 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 [[ProviderAPI|providers]]. This immediately breaks the promise of source [[BackwardCompatibility]]. |
TBD: Fragile methods additions | TBD: Fragile methods additions | ||
TBD: Interfaces and clear definition of a version | TBD: Interfaces and clear definition of a version | ||
| + | |||
| + | [[Category:APIDesignPatterns]] | ||
| + | [[Category:APIDesignPatterns:Evolution]] | ||
Revision as of 12:33, 15 November 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
