JaroslavTulach at 21:14, 29 September 2010 - 2010-09-29 21:14:17

←Older revision Revision as of 21:14, 29 September 2010
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 provider more functionality. Doing this in [[BackwardCompatibility|backward compatible]] way ensures that usages of previous version of the [[API]] still remains valid and greatly reduces [[Cost of Ownership]] and turns the [[API]] into [[Good Technology|good one]]. The [[APIDesignPatterns]] listed in this category are well suited for [[Evolution]]:
+
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]]
[[Category:APIDesignPatterns]]

JaroslavTulach at 12:51, 15 November 2008 - 2008-11-15 12:51:37

←Older revision Revision as of 12:51, 15 November 2008
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 provider more functionality. Doing this in [[BackwardCompatible]] way ensures that usages of previous version of the [[API]] still remains valid and greatly reduces [[Cost of Ownership]] and turns the [[API]] into [[Good Technology|good one]]. The [[APIDesignPatterns]] listed in this category are well suited for [[Evolution]]:
+
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 [[BackwardCompatibility|backward compatible]] way ensures that usages of previous version of the [[API]] still remains valid and greatly reduces [[Cost of Ownership]] and turns the [[API]] into [[Good Technology|good one]]. The [[APIDesignPatterns]] listed in this category are well suited for [[Evolution]]:
 +
 
 +
 
 +
[[Category:APIDesignPatterns]]

JaroslavTulach: 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... - 2008-11-15 12:46:50

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...

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 that usages of previous version of the [[API]] still remains valid and greatly reduces [[Cost of Ownership]] and turns the [[API]] into [[Good Technology|good one]]. The [[APIDesignPatterns]] listed in this category are well suited for [[Evolution]]: