Tfeiner at 13:27, 6 June 2012 - 2012-06-06 13:27:28

←Older revision Revision as of 13:27, 6 June 2012
Line 120: Line 120:
Kind regards
Kind regards
-
[[Special:Contributions/83.164.128.222|83.164.128.222]] 13:25, 6 June 2012 (UTC)
+
[[User:Tfeiner|Tfeiner]] 13:27, 6 June 2012 (UTC)

83.164.128.222 at 13:25, 6 June 2012 - 2012-06-06 13:25:48

←Older revision Revision as of 13:25, 6 June 2012
Line 119: Line 119:
Kind regards
Kind regards
 +
 +
[[Special:Contributions/83.164.128.222|83.164.128.222]] 13:25, 6 June 2012 (UTC)

83.164.128.222 at 11:18, 6 June 2012 - 2012-06-06 11:18:05

←Older revision Revision as of 11:18, 6 June 2012
Line 116: Line 116:
would it be better to use final classes or java interfaces instead?
would it be better to use final classes or java interfaces instead?
-
I really appreciate your book, because it really offers practical solutions!
+
I really appreciate your book, because it offers practical solutions!
Kind regards
Kind regards

83.164.128.222: /* Maybe a beginner question II... */ - 2012-06-05 15:56:01

Maybe a beginner question II...

←Older revision Revision as of 15:56, 5 June 2012
Line 112: Line 112:
I'm also reading your book and just finished chapter 8. I'm also a bit confused. Like the former writer said, you recommend not using Java interfaces using final classes instead.
I'm also reading your book and just finished chapter 8. I'm also a bit confused. Like the former writer said, you recommend not using Java interfaces using final classes instead.
My application uses Spring, so I try to implement it in a modularized way like suggested in Chapter 7. There you use three interfaces (Scrambler, WordLibrary and UI). Would it be possible
My application uses Spring, so I try to implement it in a modularized way like suggested in Chapter 7. There you use three interfaces (Scrambler, WordLibrary and UI). Would it be possible
-
to use final classes there instead or would this make no sense? I'm asking because I want to offer an service interface (in the mentioned broad sense), to enable the API users to proceed
+
to use final classes there instead or would this make no sense? I'm asking because I want to offer a service interface (in the mentioned broad sense) to enable the API users to proceed
certain tasks within my system. With respect to evolution of these service interfaces (which should be resolved with the aid of Spring, I cannot use another dependency injection framework here)
certain tasks within my system. With respect to evolution of these service interfaces (which should be resolved with the aid of Spring, I cannot use another dependency injection framework here)
would it be better to use final classes or java interfaces instead?
would it be better to use final classes or java interfaces instead?

83.164.128.222: /* Maybe a beginner question II... */ - 2012-06-05 15:55:23

Maybe a beginner question II...

←Older revision Revision as of 15:55, 5 June 2012
Line 110: Line 110:
Hi Jaroslav,
Hi Jaroslav,
-
I'm also reading your book and just finished chapter 8. I'm also a bit confused. Like the former writer said, you recommend not using Java interfaces and use final classes instead.
+
I'm also reading your book and just finished chapter 8. I'm also a bit confused. Like the former writer said, you recommend not using Java interfaces using final classes instead.
My application uses Spring, so I try to implement it in a modularized way like suggested in Chapter 7. There you use three interfaces (Scrambler, WordLibrary and UI). Would it be possible
My application uses Spring, so I try to implement it in a modularized way like suggested in Chapter 7. There you use three interfaces (Scrambler, WordLibrary and UI). Would it be possible
to use final classes there instead or would this make no sense? I'm asking because I want to offer an service interface (in the mentioned broad sense), to enable the API users to proceed
to use final classes there instead or would this make no sense? I'm asking because I want to offer an service interface (in the mentioned broad sense), to enable the API users to proceed

83.164.128.222 at 15:54, 5 June 2012 - 2012-06-05 15:54:56

←Older revision Revision as of 15:54, 5 June 2012
Line 104: Line 104:
--[[User:JaroslavTulach|JaroslavTulach]] 18:39, 31 August 2010 (UTC)
--[[User:JaroslavTulach|JaroslavTulach]] 18:39, 31 August 2010 (UTC)
 +
 +
 +
== Maybe a beginner question II... ==
 +
 +
Hi Jaroslav,
 +
 +
I'm also reading your book and just finished chapter 8. I'm also a bit confused. Like the former writer said, you recommend not using Java interfaces and use final classes instead.
 +
My application uses Spring, so I try to implement it in a modularized way like suggested in Chapter 7. There you use three interfaces (Scrambler, WordLibrary and UI). Would it be possible
 +
to use final classes there instead or would this make no sense? I'm asking because I want to offer an service interface (in the mentioned broad sense), to enable the API users to proceed
 +
certain tasks within my system. With respect to evolution of these service interfaces (which should be resolved with the aid of Spring, I cannot use another dependency injection framework here)
 +
would it be better to use final classes or java interfaces instead?
 +
 +
I really appreciate your book, because it really offers practical solutions!
 +
 +
Kind regards

JaroslavTulach at 18:39, 31 August 2010 - 2010-08-31 18:39:50

←Older revision Revision as of 18:39, 31 August 2010
Line 98: Line 98:
Kind regards
Kind regards
 +
 +
Hi. I hope [[TheAPIBook]] will give you some answers later. For example the [[Chapter 18]] is considered good use case study for example by [[ThanksEveryone#DaveKoelle|Dave]].
 +
 +
As far as your question about ''what'' and ''how'' goes. I think you may be right. Just with [[Java]] interfaces you have to get the ''what'' right at the first shot. I am usually not that confident and thus I rather [[Separate APIs for Clients and Providers]] usually.
 +
 +
--[[User:JaroslavTulach|JaroslavTulach]] 18:39, 31 August 2010 (UTC)

Neopium: /* Maybe a beginner question... */ new section - 2010-08-31 16:39:04

Maybe a beginner question...: new section

←Older revision Revision as of 16:39, 31 August 2010
Line 86: Line 86:
--[[User:JaroslavTulach|JaroslavTulach]] 12:32, 28 January 2009 (UTC)
--[[User:JaroslavTulach|JaroslavTulach]] 12:32, 28 January 2009 (UTC)
 +
 +
== Maybe a beginner question... ==
 +
 +
Hi Jaroslav,
 +
 +
I'm currently reading your very good book and just finished chapter 6... and I'm a bit confused by this chapter.
 +
You say "Code Against Interfaces, Not Implementations", then you recommend not using Java interfaces if I want to add methods later but instead use final classes.
 +
I don't understand how providing final classes in an API is coding against interface: final classes cannot be subclassed by definition, so if you have a final class in your API, you provide an implementation... or did I miss something ?
 +
 +
I used to design my API almost exclusively with Java interfaces. I agree that they are thus not very evolvable... But at least I define the "what" and let the user implement the "how" (most of the time, I provide a default implementation). I have the feeling that according to your advice, I have to provide my users with both the "what" and "how"... and it doesn't feel right...
 +
 +
Kind regards

JaroslavTulach: /* Usefulness of abstract classes. */ - 2009-01-28 12:32:28

Usefulness of abstract classes.

←Older revision Revision as of 12:32, 28 January 2009
Line 78: Line 78:
Great book... one of the best I've read, btw.
Great book... one of the best I've read, btw.
 +
 +
---
 +
 +
Thanks. I guess you will find answer to your question in [[Cooperating_with_Other_APIs|chapter 10]]'s ''Delegation and Composition''. The '''Arithmetica''' example shows why one shall be aware of subclassable classes in [[API]]. As usually (but not always), abstract classes behave like the subclassable ones, one shall be aware of them too.
 +
 +
Also, the [[Cooperating_with_Other_APIs|chapter 10]] also contains an algorithm for converting any subclassable class (which usually has multiple meanings) into three classes and interfaces delegating to each other. I recommend this technique as it helps the [[API]]'s clarity. I shall blog about this topic, when I find time. Thanks for asking your question.
 +
 +
--[[User:JaroslavTulach|JaroslavTulach]] 12:32, 28 January 2009 (UTC)

98.193.4.177: /* Usefulness of abstract classes. */ new section - 2009-01-27 20:47:41

Usefulness of abstract classes.: new section

←Older revision Revision as of 20:47, 27 January 2009
Line 65: Line 65:
--[[User:JesseGlick|JesseGlick]] 01:19, 8 April 2008 (UTC)
--[[User:JesseGlick|JesseGlick]] 01:19, 8 April 2008 (UTC)
 +
 +
== Usefulness of abstract classes. ==
 +
 +
on page 95 you ask- are abstract classes useful? Basically, the answer seems to be - not usually. What's not addressed is why the classic purpose of abstract classes- pluggable algorithm implementations - is not seen as useful.
 +
 +
The classic justification for an abstract class is to permit later, presumably better, implementations to be "plugged in" by the
 +
developer (API consumer) .
 +
 +
So in the book, you answer the question- can API developers safely add abstract methods (to an existing API ) but then this seems to expand into "are abstract methods ever useful?" and this is confusing me.
 +
 +
Did you mean to say that abstract classes are never useful? Or are you still talking about ADDING an abstract method to a "star" (published API class).
 +
 +
Great book... one of the best I've read, btw.