Category:APIDesignPatterns:Evolution
From APIDesign
(Difference between revisions)
(New page: First version of an API is never perfect. All the time there is a need to evolve, extend use-cases and provider more functionality. Doing this in BackwardCompatible way ensures tha...) |
|||
(One intermediate revision not shown.) | |||
Line 1: | Line 1: | ||
- | First version of an [[API]] is never perfect. All the time there is a need to evolve, extend use-cases and | + | First version of an [[API]] is never perfect. [[API]]s need to be ready for being insufficient and imagine potential direction of future changes. All the time there is a need to evolve, extend use-cases and provide more functionality. |
+ | |||
+ | Doing this in [[BackwardCompatibility|backward compatible]] way ensures that usages of previous version of the [[API]] remains valid in future. This greatly reduces [[cost of Ownership]] for users of such [[API]]s. | ||
+ | |||
+ | Evolution of an [[API]] requires well though plan. One needs to be ready for extending already existing pieces. Usage of proper [[APIDesignPatterns]] patterns listed at this category will make such future, unknown changes easier: | ||
+ | |||
+ | [[Category:APIDesignPatterns]] |
Current revision
First version of an API is never perfect. APIs need to be ready for being insufficient and imagine potential direction of future changes. All the time there is a need to evolve, extend use-cases and provide more functionality.
Doing this in backward compatible way ensures that usages of previous version of the API remains valid in future. This greatly reduces cost of Ownership for users of such APIs.
Evolution of an API requires well though plan. One needs to be ready for extending already existing pieces. Usage of proper APIDesignPatterns patterns listed at this category will make such future, unknown changes easier:
Pages in category "APIDesignPatterns:Evolution"
There are 33 pages in this category.
ABC |
C cont.DEFGIL |
MOPRV |