Talk:Code Against Interfaces, Not Implementations - Revision history

Tfeiner at 13:27, 6 June 2012

Tfeiner — Wed, 06 Jun 2012 13:27:28 GMT

←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

83.164.128.222 — Wed, 06 Jun 2012 13:25:48 GMT

←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

83.164.128.222 — Wed, 06 Jun 2012 11:18:05 GMT

←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... */

83.164.128.222 — Tue, 05 Jun 2012 15:56:01 GMT

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... */

83.164.128.222 — Tue, 05 Jun 2012 15:55:23 GMT

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

83.164.128.222 — Tue, 05 Jun 2012 15:54:56 GMT

←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

JaroslavTulach — Tue, 31 Aug 2010 18:39:50 GMT

←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

Neopium — Tue, 31 Aug 2010 16:39:04 GMT

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. */

JaroslavTulach — Wed, 28 Jan 2009 12:32:28 GMT

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

98.193.4.177 — Tue, 27 Jan 2009 20:47:41 GMT

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.