←Older revision | Revision as of 13:27, 6 June 2012 | ||
Line 120: | Line 120: | ||
Kind regards | Kind regards | ||
- | [[ | + | [[User:Tfeiner|Tfeiner]] 13:27, 6 June 2012 (UTC) |
←Older revision | Revision as of 13:27, 6 June 2012 | ||
Line 120: | Line 120: | ||
Kind regards | Kind regards | ||
- | [[ | + | [[User:Tfeiner|Tfeiner]] 13:27, 6 June 2012 (UTC) |
←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) |
←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 | + | I really appreciate your book, because it offers practical solutions! |
Kind regards | Kind regards |
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 | + | 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? |
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 | + | 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 |
←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 |
←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) |
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 |
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) |
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. |