Category:APIDesignPatterns:Evolution - Revision history

JaroslavTulach at 21:14, 29 September 2010

2010-09-29T21:14:17Z

←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-15T12:51:37Z

←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-15T12:46:50Z

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]]: