ProviderAPI
From APIDesign
(Difference between revisions)
(New page: Rules for extending API designed for implementors are very different to those for API that can only be called. In case you...) |
|||
| Line 2: | Line 2: | ||
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]]. | ||
| + | |||
| + | TBD: Fragile methods additions | ||
| + | |||
| + | TBD: Interfaces and clear definition of a version | ||
Revision as of 20:30, 22 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 that implements your interface at a given time, the obvious expectation of that person seems to be that the once provided implementation, written and potentially compile once, 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
