http://wiki.apidesign.org/index.php?title=ClientAPI&feed=atom&action=historyClientAPI - Revision history2024-03-29T06:45:46ZRevision history for this page on the wikiMediaWiki 1.12.0rc1http://wiki.apidesign.org/index.php?title=ClientAPI&diff=10218&oldid=prevJaroslavTulach at 18:48, 24 September 20202020-09-24T18:48:51Z<p></p>
<table style="background-color: white; color:black;">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr>
<td colspan='2' style="background-color: white; color:black;">←Older revision</td>
<td colspan='2' style="background-color: white; color:black;">Revision as of 18:48, 24 September 2020</td>
</tr>
<tr><td colspan="2" class="diff-lineno">Line 1:</td>
<td colspan="2" class="diff-lineno">Line 1:</td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>[[Image:OpenSpace.png|thumb|right]]</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>[[Image:OpenSpace.png|thumb|right]]</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>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 <del style="color: red; font-weight: bold; text-decoration: none;">the </del>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.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>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 <ins style="color: red; font-weight: bold; text-decoration: none;">when </ins>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.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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]]. </div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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]]. </div></td></tr>
</table>JaroslavTulachhttp://wiki.apidesign.org/index.php?title=ClientAPI&diff=4664&oldid=prevJaroslavTulach at 12:34, 21 March 20112011-03-21T12:34:23Z<p></p>
<table style="background-color: white; color:black;">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr>
<td colspan='2' style="background-color: white; color:black;">←Older revision</td>
<td colspan='2' style="background-color: white; color:black;">Revision as of 12:34, 21 March 2011</td>
</tr>
<tr><td colspan="2" class="diff-lineno">Line 1:</td>
<td colspan="2" class="diff-lineno">Line 1:</td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div><del style="color: red; font-weight: bold; text-decoration: none;">There is a difference between [[ClientAPI]] and [[ProviderAPI]] [[evolution]] rules. </del></div></td><td colspan="2"> </td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div><del style="color: red; font-weight: bold; text-decoration: none;"></del></div></td><td colspan="2"> </td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>[[Image:OpenSpace.png|thumb|right]]</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>[[Image:OpenSpace.png|thumb|right]]</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>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 <del style="color: red; font-weight: bold; text-decoration: none;">only use of your </del>[[API]] <del style="color: red; font-weight: bold; text-decoration: none;">is to </del>be called, then the obvious requirement is <del style="color: red; font-weight: bold; text-decoration: none;">to be </del>to add more methods and to allow <del style="color: red; font-weight: bold; text-decoration: none;">the </del>users to call more of exposed functionality.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;">There is a difference between [[ClientAPI]] and [[ProviderAPI]] [[evolution]] rules. </ins>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 <ins style="color: red; font-weight: bold; text-decoration: none;">the </ins>[[API]] <ins style="color: red; font-weight: bold; text-decoration: none;">can only </ins>be called, then the obvious requirement is to add more methods and to allow users to call more of <ins style="color: red; font-weight: bold; text-decoration: none;">such </ins>exposed functionality.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>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 <del style="color: red; font-weight: bold; text-decoration: none;">one</del>, don't need to care about the new ones. [[ClientAPI|Clients]] seeking <del style="color: red; font-weight: bold; text-decoration: none;">for </del>new functionality will be pleased when it <del style="color: red; font-weight: bold; text-decoration: none;">appears </del>in the ''open space'' of your [[ClientAPI]]. </div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>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 <ins style="color: red; font-weight: bold; text-decoration: none;">elements</ins>, don't need to care about the new ones. [[ClientAPI|Clients]] seeking new functionality will be pleased when it <ins style="color: red; font-weight: bold; text-decoration: none;">gets exposed </ins>in the ''open space'' of your [[ClientAPI]]. </div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>What is the most suitable coding construct in [[Java]] to support an ''open space''? The most safe one is a '''final''' class (one cannot <del style="color: red; font-weight: bold; text-decoration: none;">create </del>binary [[BackwardCompatibility]] problems by adding new methods into such class). Exposing only '''final''' classes to users of [[ClientAPI]] makes it bullet-proof: </div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>What is the most suitable coding construct in [[Java]] to support an ''open space''? The most safe one is a '''final''' class (one cannot <ins style="color: red; font-weight: bold; text-decoration: none;">cause </ins>binary [[BackwardCompatibility]] problems by adding new methods into such class). Exposing only '''final''' classes to users of <ins style="color: red; font-weight: bold; text-decoration: none;">a </ins>[[ClientAPI]] makes it bullet-proof: </div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div><source lang="java"></div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div><source lang="java"></div></td></tr>
<tr><td colspan="2" class="diff-lineno">Line 19:</td>
<td colspan="2" class="diff-lineno">Line 17:</td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div></source></div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div></source></div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>The shape of [[ProviderAPI]] is quite different. <del style="color: red; font-weight: bold; text-decoration: none;">Can you imagine the result, when you mix goals of your </del>[[<del style="color: red; font-weight: bold; text-decoration: none;">API</del>]] <del style="color: red; font-weight: bold; text-decoration: none;">and create a single class which serves as [[ClientAPI]] as well as [[ProviderAPI]]? You'll be trying </del>to <del style="color: red; font-weight: bold; text-decoration: none;">fit an </del>''open space'' <del style="color: red; font-weight: bold; text-decoration: none;">into a singular point (natural representation of a </del>[[ProviderAPI<del style="color: red; font-weight: bold; text-decoration: none;">]]). 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</del>]].</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>The shape of [[ProviderAPI]] is quite different. <ins style="color: red; font-weight: bold; text-decoration: none;">See </ins>[[<ins style="color: red; font-weight: bold; text-decoration: none;">APIvsSPI</ins>]] to <ins style="color: red; font-weight: bold; text-decoration: none;">understand what happens when you try to merge the </ins>''open space'' <ins style="color: red; font-weight: bold; text-decoration: none;">with the shape associated with </ins>[[ProviderAPI]]. </div></td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div> </div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div></div></td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div> </div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div></div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>[[Category:APIDesignPatterns]]</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>[[Category:APIDesignPatterns]]</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>[[Category:APIDesignPatterns:Evolution]]</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>[[Category:APIDesignPatterns:Evolution]]</div></td></tr>
</table>JaroslavTulachhttp://wiki.apidesign.org/index.php?title=ClientAPI&diff=4642&oldid=prevApidesign at 20:17, 19 March 20112011-03-19T20:17:52Z<p></p>
<table style="background-color: white; color:black;">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr>
<td colspan='2' style="background-color: white; color:black;">←Older revision</td>
<td colspan='2' style="background-color: white; color:black;">Revision as of 20:17, 19 March 2011</td>
</tr>
<tr><td colspan="2" class="diff-lineno">Line 7:</td>
<td colspan="2" class="diff-lineno">Line 7:</td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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]]. </div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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]]. </div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>What is the most suitable coding construct in [[Java]] to support an ''open space''? The most safe one is a '''final''' class<del style="color: red; font-weight: bold; text-decoration: none;">. As </del>such <del style="color: red; font-weight: bold; text-decoration: none;">it is suggested to expose </del>only '''final''' classes to users of [[ClientAPI]]<del style="color: red; font-weight: bold; text-decoration: none;">. </del></div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>What is the most suitable coding construct in [[Java]] to support an ''open space''? The most safe one is a '''final''' class <ins style="color: red; font-weight: bold; text-decoration: none;">(one cannot create binary [[BackwardCompatibility]] problems by adding new methods into </ins>such <ins style="color: red; font-weight: bold; text-decoration: none;">class). Exposing </ins>only '''final''' classes to users of [[ClientAPI]] <ins style="color: red; font-weight: bold; text-decoration: none;">makes it bullet-proof: </ins></div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div><source lang="java"></div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div><source lang="java"></div></td></tr>
</table>Apidesignhttp://wiki.apidesign.org/index.php?title=ClientAPI&diff=4641&oldid=prevJaroslavTulach at 20:14, 19 March 20112011-03-19T20:14:55Z<p></p>
<table style="background-color: white; color:black;">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr>
<td colspan='2' style="background-color: white; color:black;">←Older revision</td>
<td colspan='2' style="background-color: white; color:black;">Revision as of 20:14, 19 March 2011</td>
</tr>
<tr><td colspan="2" class="diff-lineno">Line 8:</td>
<td colspan="2" class="diff-lineno">Line 8:</td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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]]. </div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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]]. </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;"></ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;"><source lang="java"></ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;">public final class Player {</ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;"> public void play(File mp3);</ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;"> public void stop();</ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;"></ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;"> /** @since 2.0 we can also control volume */</ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;"> public void setVolume(int volume);</ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;">}</ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;"></source></ins></div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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]].</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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]].</div></td></tr>
</table>JaroslavTulachhttp://wiki.apidesign.org/index.php?title=ClientAPI&diff=4638&oldid=prevJaroslavTulach at 19:57, 19 March 20112011-03-19T19:57:47Z<p></p>
<table style="background-color: white; color:black;">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr>
<td colspan='2' style="background-color: white; color:black;">←Older revision</td>
<td colspan='2' style="background-color: white; color:black;">Revision as of 19:57, 19 March 2011</td>
</tr>
<tr><td colspan="2" class="diff-lineno">Line 5:</td>
<td colspan="2" class="diff-lineno">Line 5:</td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>This can be envisioned as an <del style="color: red; font-weight: bold; text-decoration: none;">[[File:OpenSpace.png|</del>open space<del style="color: red; font-weight: bold; text-decoration: none;">]] </del>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]]. </div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>This can be envisioned as an <ins style="color: red; font-weight: bold; text-decoration: none;">'''</ins>open space<ins style="color: red; font-weight: bold; text-decoration: none;">''' </ins>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]]. </div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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]]. </div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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]]. </div></td></tr>
</table>JaroslavTulachhttp://wiki.apidesign.org/index.php?title=ClientAPI&diff=4598&oldid=prevJaroslavTulach at 20:34, 7 March 20112011-03-07T20:34:35Z<p></p>
<table style="background-color: white; color:black;">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr>
<td colspan='2' style="background-color: white; color:black;">←Older revision</td>
<td colspan='2' style="background-color: white; color:black;">Revision as of 20:34, 7 March 2011</td>
</tr>
<tr><td colspan="2" class="diff-lineno">Line 1:</td>
<td colspan="2" class="diff-lineno">Line 1:</td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>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.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>There is a difference between [[ClientAPI]] and [[ProviderAPI]] <ins style="color: red; font-weight: bold; text-decoration: none;">[[</ins>evolution<ins style="color: red; font-weight: bold; text-decoration: none;">]] </ins>rules. </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;">[[Image:OpenSpace.png|thumb|right]]</ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>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.</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;">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]]. </ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;">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]]. </ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;">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]].</ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div> </div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div><del style="color: red; font-weight: bold; text-decoration: none;">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]].</del></div></td><td colspan="2"> </td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>[[Category:APIDesignPatterns]]</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>[[Category:APIDesignPatterns]]</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>[[Category:APIDesignPatterns:Evolution]]</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>[[Category:APIDesignPatterns:Evolution]]</div></td></tr>
</table>JaroslavTulachhttp://wiki.apidesign.org/index.php?title=ClientAPI&diff=4596&oldid=prevJaroslavTulach at 19:49, 7 March 20112011-03-07T19:49:12Z<p></p>
<table style="background-color: white; color:black;">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr>
<td colspan='2' style="background-color: white; color:black;">←Older revision</td>
<td colspan='2' style="background-color: white; color:black;">Revision as of 19:49, 7 March 2011</td>
</tr>
<tr><td colspan="2" class="diff-lineno">Line 1:</td>
<td colspan="2" class="diff-lineno">Line 1:</td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>There is a difference between [[ClientAPI]] and [[ProviderAPI]] evolution rules. As soon as you publish an [[API]] <del style="color: red; font-weight: bold; text-decoration: none;">targeted for others to call</del>, you, as publisher of your library, want to have <del style="color: red; font-weight: bold; text-decoration: none;">the </del>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 <del style="color: red; font-weight: bold; text-decoration: none;">that it can </del>be called, then the <del style="color: red; font-weight: bold; text-decoration: none;">common </del>requirement is <del style="color: red; font-weight: bold; text-decoration: none;">going </del>to be <del style="color: red; font-weight: bold; text-decoration: none;">a request </del>to <del style="color: red; font-weight: bold; text-decoration: none;">expose </del>more methods and to allow the users to call more functionality.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>There is a difference between [[ClientAPI]] and [[ProviderAPI]] evolution rules. As soon as you publish an [[API]], you, as <ins style="color: red; font-weight: bold; text-decoration: none;">a </ins>publisher of your library, want to have <ins style="color: red; font-weight: bold; text-decoration: none;">a </ins>freedom <ins style="color: red; font-weight: bold; text-decoration: none;">to evolve it </ins>to satisfy additional requirements of users of your library. What additional requirements can you expect? In case the only use of your <ins style="color: red; font-weight: bold; text-decoration: none;">[[</ins>API<ins style="color: red; font-weight: bold; text-decoration: none;">]] </ins>is <ins style="color: red; font-weight: bold; text-decoration: none;">to </ins>be called, then the <ins style="color: red; font-weight: bold; text-decoration: none;">obvious </ins>requirement is to be to <ins style="color: red; font-weight: bold; text-decoration: none;">add </ins>more methods and to allow the users to call more <ins style="color: red; font-weight: bold; text-decoration: none;">of exposed </ins>functionality.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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]].</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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]].</div></td></tr>
</table>JaroslavTulachhttp://wiki.apidesign.org/index.php?title=ClientAPI&diff=2756&oldid=prevJaroslavTulach at 11:29, 19 August 20092009-08-19T11:29:52Z<p></p>
<table style="background-color: white; color:black;">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr>
<td colspan='2' style="background-color: white; color:black;">←Older revision</td>
<td colspan='2' style="background-color: white; color:black;">Revision as of 11:29, 19 August 2009</td>
</tr>
<tr><td colspan="2" class="diff-lineno">Line 1:</td>
<td colspan="2" class="diff-lineno">Line 1:</td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>There is a difference between [[ClientAPI]] and [[<del style="color: red; font-weight: bold; text-decoration: none;">APIDesignPatterns:</del>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.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>There is a difference between [[ClientAPI]] and [[ProviderAPI]] evolution rules. As soon as you publish an <ins style="color: red; font-weight: bold; text-decoration: none;">[[</ins>API<ins style="color: red; font-weight: bold; text-decoration: none;">]] </ins>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.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>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]].</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>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 <ins style="color: red; font-weight: bold; text-decoration: none;">is </ins>suggested to expose only final classes to users of [[ClientAPI<ins style="color: red; font-weight: bold; text-decoration: none;">]]. If you publish non-final class, or even interface, you'll face [[evolution]] problems as described at [[ExtendingInterfaces</ins>]].</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>[[Category:APIDesignPatterns]]</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>[[Category:APIDesignPatterns]]</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>[[Category:APIDesignPatterns:Evolution]]</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>[[Category:APIDesignPatterns:Evolution]]</div></td></tr>
</table>JaroslavTulachhttp://wiki.apidesign.org/index.php?title=ClientAPI&diff=1663&oldid=prevJaroslavTulach at 12:32, 15 November 20082008-11-15T12:32:54Z<p></p>
<table style="background-color: white; color:black;">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr>
<td colspan='2' style="background-color: white; color:black;">←Older revision</td>
<td colspan='2' style="background-color: white; color:black;">Revision as of 12:32, 15 November 2008</td>
</tr>
<tr><td colspan="2" class="diff-lineno">Line 1:</td>
<td colspan="2" class="diff-lineno">Line 1:</td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>There is a difference between [[<del style="color: red; font-weight: bold; text-decoration: none;">APIDesignPatterns:</del>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.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>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.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>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 [[<del style="color: red; font-weight: bold; text-decoration: none;">APIDesignPatterns:</del>ClientAPI]].</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>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]].</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;">[[Category:APIDesignPatterns]]</ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;">[[Category:APIDesignPatterns:Evolution]]</ins></div></td></tr>
</table>JaroslavTulachhttp://wiki.apidesign.org/index.php?title=ClientAPI&diff=1661&oldid=prevJaroslavTulach: APIDesignPatterns:ClientAPI moved to ClientAPI: Shorter names for use with categories2008-11-15T12:32:00Z<p><a href="/wiki/APIDesignPatterns:ClientAPI" class="mw-redirect" title="APIDesignPatterns:ClientAPI">APIDesignPatterns:ClientAPI</a> moved to <a href="/wiki/ClientAPI" title="ClientAPI">ClientAPI</a>: Shorter names for use with categories</p>
<table style="background-color: white; color:black;">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr>
<td colspan='2' style="background-color: white; color:black;">←Older revision</td>
<td colspan='2' style="background-color: white; color:black;">Revision as of 12:32, 15 November 2008</td>
</tr>
</table>JaroslavTulach