[[Image:OpenSpace.png|thumb|right]]

[[Image:OpenSpace.png|thumb|right]]

There is a difference between [[ClientAPI]] and [[ProviderAPI]] [[evolution]] rules. As soon as you publish an [[API]], you, as a publisher of your library, want to have a freedom to evolve it to satisfy additional requirements of users of your library. What additional requirements can you expect? In case the the [[API]] can only be called, then the obvious requirement is to add more methods and to allow users to call more of such exposed functionality.

There is a difference between [[ClientAPI]] and [[ProviderAPI]] [[evolution]] rules. As soon as you publish an [[API]], you, as a publisher of your library, want to have a freedom to evolve it to satisfy additional requirements of users of your library. What additional requirements can you expect? In case when the [[API]] can only be called, then the obvious requirement is to add more methods and to allow users to call more of such exposed functionality.

This can be envisioned as an '''open space''' which grows with a time. To keep [[BackwardCompatibility]], every method, field or class which has been present in previous releases, needs to stay. New methods can however be added as requested. Those [[ClientAPI|clients]] that used to call the previously existing elements, don't need to care about the new ones. [[ClientAPI|Clients]] seeking new functionality will be pleased when it gets exposed in the ''open space'' of your [[ClientAPI]].

This can be envisioned as an '''open space''' which grows with a time. To keep [[BackwardCompatibility]], every method, field or class which has been present in previous releases, needs to stay. New methods can however be added as requested. Those [[ClientAPI|clients]] that used to call the previously existing elements, don't need to care about the new ones. [[ClientAPI|Clients]] seeking new functionality will be pleased when it gets exposed in the ''open space'' of your [[ClientAPI]].

[[Image:OpenSpace.png|thumb|right]]

[[Image:OpenSpace.png|thumb|right]]

As soon as you publish an [[API]], you, as a publisher of your library, want to have a freedom to evolve it to satisfy additional requirements of users of your library. What additional requirements can you expect? In case the only use of your [[API]] is to be called, then the obvious requirement is to be to add more methods and to allow the users to call more of exposed functionality.

There is a difference between [[ClientAPI]] and [[ProviderAPI]] [[evolution]] rules. As soon as you publish an [[API]], you, as a publisher of your library, want to have a freedom to evolve it to satisfy additional requirements of users of your library. What additional requirements can you expect? In case the the [[API]] can only be called, then the obvious requirement is to add more methods and to allow users to call more of such exposed functionality.

This can be envisioned as an '''open space''' which grows with a time. To keep [[BackwardCompatibility]], every method, field or class which has been present in previous releases, needs to stay. New methods can however be added as requested. Those [[ClientAPI|clients]] that used to call the previously existing one, don't need to care about the new ones. [[ClientAPI|Clients]] seeking for new functionality will be pleased when it appears in the ''open space'' of your [[ClientAPI]].

This can be envisioned as an '''open space''' which grows with a time. To keep [[BackwardCompatibility]], every method, field or class which has been present in previous releases, needs to stay. New methods can however be added as requested. Those [[ClientAPI|clients]] that used to call the previously existing elements, don't need to care about the new ones. [[ClientAPI|Clients]] seeking new functionality will be pleased when it gets exposed in the ''open space'' of your [[ClientAPI]].

What is the most suitable coding construct in [[Java]] to support an ''open space''? The most safe one is a '''final''' class (one cannot create binary [[BackwardCompatibility]] problems by adding new methods into such class). Exposing only '''final''' classes to users of [[ClientAPI]] makes it bullet-proof:

What is the most suitable coding construct in [[Java]] to support an ''open space''? The most safe one is a '''final''' class (one cannot cause binary [[BackwardCompatibility]] problems by adding new methods into such class). Exposing only '''final''' classes to users of a [[ClientAPI]] makes it bullet-proof:

<source lang="java">

<source lang="java">

</source>

</source>

The shape of [[ProviderAPI]] is quite different. Can you imagine the result, when you mix goals of your [[API]] and create a single class which serves as [[ClientAPI]] as well as [[ProviderAPI]]? You'll be trying to fit an ''open space'' into a singular point (natural representation of a [[ProviderAPI]]). The result is that you'll be forbidden to [[evolution|evolve]] your [[API]] in any way. If you publish non-final class, or even interface, you'll face [[evolution]] problems as described at [[ExtendingInterfaces]].

The shape of [[ProviderAPI]] is quite different. See [[APIvsSPI]] to understand what happens when you try to merge the ''open space'' with the shape associated with [[ProviderAPI]].

 

 

[[Category:APIDesignPatterns]]

[[Category:APIDesignPatterns]]

[[Category:APIDesignPatterns:Evolution]]

[[Category:APIDesignPatterns:Evolution]]

This can be envisioned as an '''open space''' which grows with a time. To keep [[BackwardCompatibility]], every method, field or class which has been present in previous releases, needs to stay. New methods can however be added as requested. Those [[ClientAPI|clients]] that used to call the previously existing one, don't need to care about the new ones. [[ClientAPI|Clients]] seeking for new functionality will be pleased when it appears in the ''open space'' of your [[ClientAPI]].

This can be envisioned as an '''open space''' which grows with a time. To keep [[BackwardCompatibility]], every method, field or class which has been present in previous releases, needs to stay. New methods can however be added as requested. Those [[ClientAPI|clients]] that used to call the previously existing one, don't need to care about the new ones. [[ClientAPI|Clients]] seeking for new functionality will be pleased when it appears in the ''open space'' of your [[ClientAPI]].

What is the most suitable coding construct in [[Java]] to support an ''open space''? The most safe one is a '''final''' class. As such it is suggested to expose only '''final''' classes to users of [[ClientAPI]].

What is the most suitable coding construct in [[Java]] to support an ''open space''? The most safe one is a '''final''' class (one cannot create binary [[BackwardCompatibility]] problems by adding new methods into such class). Exposing only '''final''' classes to users of [[ClientAPI]] makes it bullet-proof:

<source lang="java">

<source lang="java">

What is the most suitable coding construct in [[Java]] to support an ''open space''? The most safe one is a '''final''' class. As such it is suggested to expose only '''final''' classes to users of [[ClientAPI]].

What is the most suitable coding construct in [[Java]] to support an ''open space''? The most safe one is a '''final''' class. As such it is suggested to expose only '''final''' classes to users of [[ClientAPI]].

The shape of [[ProviderAPI]] is quite different. Can you imagine the result, when you mix goals of your [[API]] and create a single class which serves as [[ClientAPI]] as well as [[ProviderAPI]]? You'll be trying to fit an ''open space'' into a singular point (natural representation of a [[ProviderAPI]]). The result is that you'll be forbidden to [[evolution|evolve]] your [[API]] in any way. If you publish non-final class, or even interface, you'll face [[evolution]] problems as described at [[ExtendingInterfaces]].

The shape of [[ProviderAPI]] is quite different. Can you imagine the result, when you mix goals of your [[API]] and create a single class which serves as [[ClientAPI]] as well as [[ProviderAPI]]? You'll be trying to fit an ''open space'' into a singular point (natural representation of a [[ProviderAPI]]). The result is that you'll be forbidden to [[evolution|evolve]] your [[API]] in any way. If you publish non-final class, or even interface, you'll face [[evolution]] problems as described at [[ExtendingInterfaces]].

As soon as you publish an [[API]], you, as a publisher of your library, want to have a freedom to evolve it to satisfy additional requirements of users of your library. What additional requirements can you expect? In case the only use of your [[API]] is to be called, then the obvious requirement is to be to add more methods and to allow the users to call more of exposed functionality.

As soon as you publish an [[API]], you, as a publisher of your library, want to have a freedom to evolve it to satisfy additional requirements of users of your library. What additional requirements can you expect? In case the only use of your [[API]] is to be called, then the obvious requirement is to be to add more methods and to allow the users to call more of exposed functionality.

This can be envisioned as an [[File:OpenSpace.png|open space]] which grows with a time. To keep [[BackwardCompatibility]], every method, field or class which has been present in previous releases, needs to stay. New methods can however be added as requested. Those [[ClientAPI|clients]] that used to call the previously existing one, don't need to care about the new ones. [[ClientAPI|Clients]] seeking for new functionality will be pleased when it appears in the ''open space'' of your [[ClientAPI]].

This can be envisioned as an '''open space''' which grows with a time. To keep [[BackwardCompatibility]], every method, field or class which has been present in previous releases, needs to stay. New methods can however be added as requested. Those [[ClientAPI|clients]] that used to call the previously existing one, don't need to care about the new ones. [[ClientAPI|Clients]] seeking for new functionality will be pleased when it appears in the ''open space'' of your [[ClientAPI]].

What is the most suitable coding construct in [[Java]] to support an ''open space''? The most safe one is a '''final''' class. As such it is suggested to expose only '''final''' classes to users of [[ClientAPI]].

What is the most suitable coding construct in [[Java]] to support an ''open space''? The most safe one is a '''final''' class. As such it is suggested to expose only '''final''' classes to users of [[ClientAPI]].

There is a difference between [[ClientAPI]] and [[ProviderAPI]] evolution rules. As soon as you publish an [[API]], you, as a publisher of your library, want to have a freedom to evolve it to satisfy additional requirements of users of your library. What additional requirements can you expect? In case the only use of your [[API]] is to be called, then the obvious requirement is to be to add more methods and to allow the users to call more of exposed functionality.

There is a difference between [[ClientAPI]] and [[ProviderAPI]] [[evolution]] rules.

 

 

As soon as you publish an [[API]], you, as a publisher of your library, want to have a freedom to evolve it to satisfy additional requirements of users of your library. What additional requirements can you expect? In case the only use of your [[API]] is to be called, then the obvious requirement is to be to add more methods and to allow the users to call more of exposed functionality.

 

 

 

 

[[Category:APIDesignPatterns]]

[[Category:APIDesignPatterns]]

[[Category:APIDesignPatterns:Evolution]]

[[Category:APIDesignPatterns:Evolution]]

There is a difference between [[ClientAPI]] and [[ProviderAPI]] evolution rules. As soon as you publish an [[API]] targeted for others to call, you, as publisher of your library, want to have the freedom to satisfy additional requirements of users of your library. What additional requirements can you expect? In case the only use of your API is that it can be called, then the common requirement is going to be a request to expose more methods and to allow the users to call more functionality.

There is a difference between [[ClientAPI]] and [[ProviderAPI]] evolution rules. As soon as you publish an [[API]], you, as a publisher of your library, want to have a freedom to evolve it to satisfy additional requirements of users of your library. What additional requirements can you expect? In case the only use of your [[API]] is to be called, then the obvious requirement is to be to add more methods and to allow the users to call more of exposed functionality.

What is the most suitable coding construct in [[Java]] to support [[BackwardCompatibility|backward compatible]] additions of new methods? The most safe one is a final class. As such it is suggested to expose only final classes to users of [[ClientAPI]]. If you publish non-final class, or even interface, you'll face [[evolution]] problems as described at [[ExtendingInterfaces]].

What is the most suitable coding construct in [[Java]] to support [[BackwardCompatibility|backward compatible]] additions of new methods? The most safe one is a final class. As such it is suggested to expose only final classes to users of [[ClientAPI]]. If you publish non-final class, or even interface, you'll face [[evolution]] problems as described at [[ExtendingInterfaces]].

There is a difference between [[ClientAPI]] and [[APIDesignPatterns:ProviderAPI]] evolution rules. As soon as you publish an API targeted for others to call, you, as publisher of your library, want to have the freedom to satisfy additional requirements of users of your library. What additional requirements can you expect? In case the only use of your API is that it can be called, then the common requirement is going to be a request to expose more methods and to allow the users to call more functionality.

There is a difference between [[ClientAPI]] and [[ProviderAPI]] evolution rules. As soon as you publish an [[API]] targeted for others to call, you, as publisher of your library, want to have the freedom to satisfy additional requirements of users of your library. What additional requirements can you expect? In case the only use of your API is that it can be called, then the common requirement is going to be a request to expose more methods and to allow the users to call more functionality.

What is the most suitable coding construct in [[Java]] to support [[BackwardCompatibility|backward compatible]] additions of new methods? The most safe one is a final class. As such it suggested to expose only final classes to users of [[ClientAPI]].

What is the most suitable coding construct in [[Java]] to support [[BackwardCompatibility|backward compatible]] additions of new methods? The most safe one is a final class. As such it is suggested to expose only final classes to users of [[ClientAPI]]. If you publish non-final class, or even interface, you'll face [[evolution]] problems as described at [[ExtendingInterfaces]].

[[Category:APIDesignPatterns]]

[[Category:APIDesignPatterns]]

[[Category:APIDesignPatterns:Evolution]]

[[Category:APIDesignPatterns:Evolution]]

There is a difference between [[APIDesignPatterns:ClientAPI]] and [[APIDesignPatterns:ProviderAPI]] evolution rules. As soon as you publish an API targeted for others to call, you, as publisher of your library, want to have the freedom to satisfy additional requirements of users of your library. What additional requirements can you expect? In case the only use of your API is that it can be called, then the common requirement is going to be a request to expose more methods and to allow the users to call more functionality.

There is a difference between [[ClientAPI]] and [[APIDesignPatterns:ProviderAPI]] evolution rules. As soon as you publish an API targeted for others to call, you, as publisher of your library, want to have the freedom to satisfy additional requirements of users of your library. What additional requirements can you expect? In case the only use of your API is that it can be called, then the common requirement is going to be a request to expose more methods and to allow the users to call more functionality.

What is the most suitable coding construct in [[Java]] to support [[BackwardCompatibility|backward compatible]] additions of new methods? The most safe one is a final class. As such it suggested to expose only final classes to users of [[APIDesignPatterns:ClientAPI]].

What is the most suitable coding construct in [[Java]] to support [[BackwardCompatibility|backward compatible]] additions of new methods? The most safe one is a final class. As such it suggested to expose only final classes to users of [[ClientAPI]].