JaroslavTulach at 03:14, 12 September 2009 - 2009-09-12 03:14:50

←Older revision Revision as of 03:14, 12 September 2009
Line 3: Line 3:
Have you ever subclassed some API class and started to ask yourself: "Shall I override its particular method or just call it?" Or: "Is this method public because external users shall call it or am I supposed to override it?". [[Separate APIs for Clients and Providers|Chapter 8]] brings you answer to such common worries. It analyses the differences between evolution of APIs targeted to different clients, analyses what kind of messages various Java access modifiers carry and gives a recipe to convert a class full of methods with unclear multiple meanings into an API that carries just one, clear message for every developer using it.
Have you ever subclassed some API class and started to ask yourself: "Shall I override its particular method or just call it?" Or: "Is this method public because external users shall call it or am I supposed to override it?". [[Separate APIs for Clients and Providers|Chapter 8]] brings you answer to such common worries. It analyses the differences between evolution of APIs targeted to different clients, analyses what kind of messages various Java access modifiers carry and gives a recipe to convert a class full of methods with unclear multiple meanings into an API that carries just one, clear message for every developer using it.
-
=== The Writer ===
+
== The Writer ==
Significant part of this chapter builds a showcase around the Writer example. Do you know that in JDK 1.5 new methods has been added into the Writer class to work with CharSequences? Yes, it was. Could it be left abstract? No, that would not be compatible! It needed some implementation. Some, but which one? There seems to be multiple implementation choices to use. Now a small quiz: "which one would you choose?"
Significant part of this chapter builds a showcase around the Writer example. Do you know that in JDK 1.5 new methods has been added into the Writer class to work with CharSequences? Yes, it was. Could it be left abstract? No, that would not be compatible! It needed some implementation. Some, but which one? There seems to be multiple implementation choices to use. Now a small quiz: "which one would you choose?"
Line 23: Line 23:
There must be more effective way to do this! Yes, it is. Please read the chapter 8 of [[TheAPIBook]] to learn what to do and how to prevent situations like this.
There must be more effective way to do this! Yes, it is. Please read the chapter 8 of [[TheAPIBook]] to learn what to do and how to prevent situations like this.
-
=== [[Errata 8|Errata]] ===
+
== [[Errata 8|Errata]] ==
{{:Errata 8}}
{{:Errata 8}}

JaroslavTulach at 18:39, 31 July 2009 - 2009-07-31 18:39:43

←Older revision Revision as of 18:39, 31 July 2009
Line 22: Line 22:
There must be more effective way to do this! Yes, it is. Please read the chapter 8 of [[TheAPIBook]] to learn what to do and how to prevent situations like this.
There must be more effective way to do this! Yes, it is. Please read the chapter 8 of [[TheAPIBook]] to learn what to do and how to prevent situations like this.
 +
 +
=== [[Errata 8|Errata]] ===
 +
 +
{{:Errata 8}}

JaroslavTulach: /* Have You Ever Wondered...? */ - 2008-08-17 19:39:07

Have You Ever Wondered...?

←Older revision Revision as of 19:39, 17 August 2008
Line 1: Line 1:
== Have You Ever Wondered...? ==
== Have You Ever Wondered...? ==
-
Have you ever subclassed some API class and started to ask yourself: "Shall I override its particular method or just call it?" Or: "Is this method public because external users shall call it or am I supposed to override it?". [[Separate APIs for Clients and Providers|Chapter 8]] brings you answer to such common worries. It analyses the differences between evolutions of APIs targeted to different clients, analyses what kind of messages various Java access modifiers carry and gives a recipe to convert a class full of unclear methods, full of multiple meanings into an API that carries just one, clear message for every developer using it.
+
Have you ever subclassed some API class and started to ask yourself: "Shall I override its particular method or just call it?" Or: "Is this method public because external users shall call it or am I supposed to override it?". [[Separate APIs for Clients and Providers|Chapter 8]] brings you answer to such common worries. It analyses the differences between evolution of APIs targeted to different clients, analyses what kind of messages various Java access modifiers carry and gives a recipe to convert a class full of methods with unclear multiple meanings into an API that carries just one, clear message for every developer using it.
=== The Writer ===
=== The Writer ===

JaroslavTulach: /* Have You Ever Wondered...? */ - 2008-08-17 19:37:57

Have You Ever Wondered...?

←Older revision Revision as of 19:37, 17 August 2008
Line 1: Line 1:
== Have You Ever Wondered...? ==
== Have You Ever Wondered...? ==
-
Have you ever subclassed some API class and started to ask yourself: "Shall I override its particular method or just call it?" Or: "Is this method public because external users shall call it or am I supposed to override it?". This chapter brings you answer to such common worries. It analyses the differences between evolutions of APIs targeted to different clients, analyses what kind of messages various Java access modifiers carry and gives a recipe to convert a class full of unclear methods, full of multiple meanings into an API that carries just one, clear message for every developer using it.
+
Have you ever subclassed some API class and started to ask yourself: "Shall I override its particular method or just call it?" Or: "Is this method public because external users shall call it or am I supposed to override it?". [[Separate APIs for Clients and Providers|Chapter 8]] brings you answer to such common worries. It analyses the differences between evolutions of APIs targeted to different clients, analyses what kind of messages various Java access modifiers carry and gives a recipe to convert a class full of unclear methods, full of multiple meanings into an API that carries just one, clear message for every developer using it.
=== The Writer ===
=== The Writer ===

JaroslavTulach: Separate APIs for Client APIs and Support APIs moved to Separate APIs for Clients and Providers: Adjusting to the title in the printed version of the book - 2008-08-14 08:16:30

Separate APIs for Client APIs and Support APIs moved to Separate APIs for Clients and Providers: Adjusting to the title in the printed version of the book

←Older revision Revision as of 08:16, 14 August 2008

JaroslavTulach at 05:03, 3 August 2008 - 2008-08-03 05:03:42

←Older revision Revision as of 05:03, 3 August 2008
Line 1: Line 1:
 +
== Have You Ever Wondered...? ==
 +
 +
Have you ever subclassed some API class and started to ask yourself: "Shall I override its particular method or just call it?" Or: "Is this method public because external users shall call it or am I supposed to override it?". This chapter brings you answer to such common worries. It analyses the differences between evolutions of APIs targeted to different clients, analyses what kind of messages various Java access modifiers carry and gives a recipe to convert a class full of unclear methods, full of multiple meanings into an API that carries just one, clear message for every developer using it.
 +
=== The Writer ===
=== The Writer ===
-
This chapter analyses the Writer example. Do you know that in JDK 1.5 new methods has been added into the Writer class to work with CharSequences? Of course, they could not be left abstract, as that would not be compatible. They needed some implementation. Of course, there are multiple choices to use. So, which one would you choose?
+
Significant part of this chapter builds a showcase around the Writer example. Do you know that in JDK 1.5 new methods has been added into the Writer class to work with CharSequences? Yes, it was. Could it be left abstract? No, that would not be compatible! It needed some implementation. Some, but which one? There seems to be multiple implementation choices to use. Now a small quiz: "which one would you choose?"
<source lang="java" snippet="writer.throw"/>
<source lang="java" snippet="writer.throw"/>

JaroslavTulach: Question about Writer - 2008-07-07 11:03:46

Question about Writer

←Older revision Revision as of 11:03, 7 July 2008
Line 1: Line 1:
 +
=== The Writer ===
 +
This chapter analyses the Writer example. Do you know that in JDK 1.5 new methods has been added into the Writer class to work with CharSequences? Of course, they could not be left abstract, as that would not be compatible. They needed some implementation. Of course, there are multiple choices to use. So, which one would you choose?
 +
 +
<source lang="java" snippet="writer.throw"/>
 +
 +
Possible, but useless, for clients calling the Writer.append method. They would always have to code very defensively, as shown here:
 +
 +
<source lang="java" snippet="writer.throw.client"/>
 +
 +
Of course, this is a very horrible API. You want to guarantee to clients calling into Writer that reasonable implementation of the append method is provided:
 +
 +
<source lang="java" snippet="writer.super"/>
 +
 +
This looks good, as clients can always rely on the append method to be implemented. Even by writers written against JDK 1.4 version of the Writer. This is not bad, however it is also not very efficient, as it always converts the whole CharSequence to String. In case of big sequences, like onces representing whole CD, this is a way to ask for OutOfMemoryErrors:
 +
 +
<source lang="java" snippet="writer.countcd"/>
 +
 +
There must be more effective way to do this! Yes, it is. Please read the chapter 8 of [[TheAPIBook]] to learn what to do and how to prevent situations like this.

Apidesign: Removing all content from page - 2008-06-14 05:57:29

Removing all content from page

←Older revision Revision as of 05:57, 14 June 2008
Line 1: Line 1:
-
'''Done: 9da22fb3cc94'''
 
-
The name of the chapter doesn't make any sense to me. How about "Separating APIs into Client API's and Service Provider API's"?
 
-
 
-
Page 120, para 2: "WinAmp" should be "Winamp".
 
-
 
-
--[[User:AndreiBadea|AndreiBadea]] 13:22, 8 April 2008 (UTC)
 

JaroslavTulach at 15:01, 19 April 2008 - 2008-04-19 15:01:22

←Older revision Revision as of 15:01, 19 April 2008
Line 1: Line 1:
 +
'''Done: 9da22fb3cc94'''
 +
The name of the chapter doesn't make any sense to me. How about "Separating APIs into Client API's and Service Provider API's"?
The name of the chapter doesn't make any sense to me. How about "Separating APIs into Client API's and Service Provider API's"?

AndreiBadea: New page: The name of the chapter doesn't make any sense to me. How about "Separating APIs into Client API's and Service Provider API's"? Page 120, para 2: "WinAmp" should be "Winamp". --~~~~ - 2008-04-08 13:22:57

New page: The name of the chapter doesn't make any sense to me. How about "Separating APIs into Client API's and Service Provider API's"? Page 120, para 2: "WinAmp" should be "Winamp". --~~~~

New page

The name of the chapter doesn't make any sense to me. How about "Separating APIs into Client API's and Service Provider API's"?

Page 120, para 2: "WinAmp" should be "Winamp".

--[[User:AndreiBadea|AndreiBadea]] 13:22, 8 April 2008 (UTC)