Re: interface instead of implementation
On Mon, 2002-11-11 at 18:15, Jeremias Maerki wrote: Hi Peter Sorry, that question slipped away under my fingers. But thanks, Kevin, for this excellent answer. I couldn't have done it better. So if I may provide a short answer to your question and to sum up the mail by Kevin: IMO the cost, if any, is by far not enough to outweigh the benefits (code readability, clear design, maintenance costs etc) of using the interface instead of the implementation. And I agree that instanceof is to be used with caution. In fact it's better than that. Interfaces have NO cost. The only cost is if you need to cast from the interface to the concrete class (which you should not need to do). Casting has a cost, it's small (and very vm dependent) the same for instanceof and usually not worth the the effort to avoid. instanceof may indicate design problems (not always, but often). -k. On Mon, 11 Nov 2002 09:18:44 +1000 Peter B. West wrote: Jeremias, This was a serious question, really. Joerg, when he gets back, might like to comment on this, because it was as a result of some of his input that I first realised there was a significant cost associated with such Java fundamentals as instanceof and type casting. Those discussions gave me much food for thought. So I'll rephrase the question: what, if anything, is the cost of using the interface instead of the implementation? Peter Peter B. West wrote: Jeremias, I have no objection at all, as long as it costs nothing. It is free, isn't it? Jeremias Maerki wrote: Fellow FOP developers, would you mind using the interface instead of the implementation where possible? Map instead of HashMap, List instead of ArrayList. I've seen this habit in a number of places and not only by Keiron! I've made it a habit to follow this pattern Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- If you don't test then your code is only a collection of bugs which apparently behave like a working program. Website: http://www.rocketred.com.au/blogs/kevin/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: interface instead of implementation
Jeremias, This was a serious question, really. Joerg, when he gets back, might like to comment on this, because it was as a result of some of his input that I first realised there was a significant cost associated with such Java fundamentals as instanceof and type casting. Those discussions gave me much food for thought. So I'll rephrase the question: what, if anything, is the cost of using the interface instead of the implementation? Peter Peter B. West wrote: Jeremias, I have no objection at all, as long as it costs nothing. It is free, isn't it? Jeremias Maerki wrote: Fellow FOP developers, would you mind using the interface instead of the implementation where possible? Map instead of HashMap, List instead of ArrayList. I've seen this habit in a number of places and not only by Keiron! I've made it a habit to follow this pattern -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: interface instead of implementation
On Mon, 2002-11-11 at 10:18, Peter B. West wrote:
Jeremias,
This was a serious question, really. Joerg, when he gets back, might
like to comment on this, because it was as a result of some of his input
that I first realised there was a significant cost associated with such
Java fundamentals as instanceof and type casting. Those discussions
gave me much food for thought. So I'll rephrase the question: what, if
anything, is the cost of using the interface instead of the implementation?
There is very little difference between casting and the instanceof
operator. Both are a single op in the bytecode (use javap to look at the
generated byte code). The speed of the operations are largely determined
by the vm (no shit sherlock :)).
For a look at the op codes here is a cheesy bit of code.
public class Casting
{
public void test()
{
Cast1 testInstance = new Cast2();
if (testInstance instanceof Cast2)
{
System.out.println(Instance of Cast2);
}
// cast to subclass
Cast2 subClassVersion = (Cast2) testInstance;
// cast to interface
CastInterface interfaceFromCast1Version = (CastInterface) testInstance;
// cast to interface from implementing class
CastInterface interfaceFromCast2Version = subClassVersion;
testInstance = subClassVersion;
}
public interface CastInterface
{
CastInterface getInstance();
}
public static class Cast1
{
public String foo;
}
public static class Cast2 extends Cast1 implements CastInterface
{
public CastInterface getInstance()
{
return this;
}
}
}
and the resulting bytecode for the test method
Method void test()
0 new #2 Class Casting. Cast2
3 dup
4 invokespecial #3 Method Casting. Cast2()
7 astore_1
8 aload_1
9 instanceof #2 Class Casting. Cast2
12 ifeq 23
15 getstatic #4 Field java.io.PrintStream out
18 ldc #5 String Instance of Cast2
20 invokevirtual #6 Method void println(java.lang.String)
23 aload_1
24 checkcast #2 Class Casting. Cast2
27 astore_2
28 aload_1
29 checkcast #7 Interface Casting. CastInterface
32 astore_3
33 aload_2
34 astore 4
36 aload_2
37 astore_1
38 return
op 8 - 12 deal with the instanceof test
op 23 - 27 are the class cast
op 28 - 32 are the interface cast
op 33 - 34 are the interface assign
op 36 - 37 are the class assign
the casting operations invoke one extra opcode.
Castiong and Performace
The pattern I use is to expose the objects via their interface but
internal method access the implementation class. This allows external
use without casting, leave me to decide which concrete implementation is
more applicable. A good example of this is ArrayList vs LinkedList;
simply expose List and determine the concrete class that is suited to
the situation, if you get it wrong you can replace the concrete without
violating your external contracts.
Because java lacks templates (bring on 1.5) there will always be a cost
associated with generic collection usage (in most cases you have to cast
to get access to the information you want).
The only place I take a second look at casting then is in large loops
(where the negative opcode jump usually costs a lot more than the cast)
instanceof usage always worries me a little, it can be an indication
that there is a problem in encapsulation and interface provision. The
most common usage is when the interface is used as a marker interface
(eg serializable). The correctness of this is a point that can be
debated.
I've seen people skipping the instanceof check and doing a speculative
cast and empty catch. On older vms this was sometimes faster, in my
recent tests this is not the case. My advice, don't do it.
Optimization - know the outcomes but leave it until the end.
When you code, understand what a cast will do, understand how to use
StringBuffers and Strings, don't apply an optimization unless it's
blatantly obvious.
I've seem many cases where developers have heard that something is a
performance problem, heard about the solution then apply that solution
everywhere without understanding the performance issue. Often this leads
to no improvement in speed but always leads to increased problems in
code maintenance (StringBuffer usage is a classic example).
When you do optimize do it with a profiler and profile a couple of vms.
What is an improvement in one is not always an improvement in the other.
Unwinding loops will usually come well before casting.
Enough rambling about casting and one final point on interfaces. Use
them on every published method you can. They will allow you to tune the
internals of your class without effecting the published contract.
-k.
Peter
Peter B. West wrote:
Jeremias,
I have no objection at all, as long as it costs nothing. It is free,
isn't it?
Jeremias Maerki wrote:
Re: interface instead of implementation
Hi Peter Sorry, that question slipped away under my fingers. But thanks, Kevin, for this excellent answer. I couldn't have done it better. So if I may provide a short answer to your question and to sum up the mail by Kevin: IMO the cost, if any, is by far not enough to outweigh the benefits (code readability, clear design, maintenance costs etc) of using the interface instead of the implementation. And I agree that instanceof is to be used with caution. On Mon, 11 Nov 2002 09:18:44 +1000 Peter B. West wrote: Jeremias, This was a serious question, really. Joerg, when he gets back, might like to comment on this, because it was as a result of some of his input that I first realised there was a significant cost associated with such Java fundamentals as instanceof and type casting. Those discussions gave me much food for thought. So I'll rephrase the question: what, if anything, is the cost of using the interface instead of the implementation? Peter Peter B. West wrote: Jeremias, I have no objection at all, as long as it costs nothing. It is free, isn't it? Jeremias Maerki wrote: Fellow FOP developers, would you mind using the interface instead of the implementation where possible? Map instead of HashMap, List instead of ArrayList. I've seen this habit in a number of places and not only by Keiron! I've made it a habit to follow this pattern Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: interface instead of implementation
On Wednesday 06 November 2002 16:18, Jeremias Maerki wrote: . . . would you mind using the interface instead of the implementation where possible? big +1. The only drawback is when you need to clone Collections, but the benefits far outweigh this I think. Maybe a minimal best practices or style guide document for developers would be nice, I don't think there is one already? -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: interface instead of implementation
On Wed, 6 Nov 2002 16:25:24 +0100 Bertrand Delacretaz wrote: On Wednesday 06 November 2002 16:18, Jeremias Maerki wrote: . . . would you mind using the interface instead of the implementation where possible? big +1. Thanks for your support. The only drawback is when you need to clone Collections, but the benefits far outweigh this I think. I agree. Maybe a minimal best practices or style guide document for developers would be nice, I don't think there is one already? We've discussed coding style issues a few weeks ago. But we still haven't hammered anything down, I think. Still on my todo list. I'll have time for this in two or three weeks. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: interface instead of implementation
I wholeheartedly agree. This is really just good style in general. Maybe we should seriously consider a FOP developer coding standard and start writing it down and putting it on the site. I'd offer to help with that. -Original Message- From: Jeremias Maerki [mailto:dev.jeremias;greenmail.ch] Sent: Wednesday, November 06, 2002 10:19 AM To: [EMAIL PROTECTED] Subject: interface instead of implementation Fellow FOP developers, would you mind using the interface instead of the implementation where possible? Map instead of HashMap, List instead of ArrayList. I've seen this habit in a number of places and not only by Keiron! I've made it a habit to follow this pattern: import java.util.List; [..] private List myvalues = new java.util.ArrayList(); ArrayList never gets imported. That makes it easier to switch between implementation, for example if you have to switch between the unsynchronized ArrayList and the synchronized Vector. The decision which implementation to take should happen at one place in the code, not at many places. For Map there exist new implementations in Jakarta Commons Collections, for example. A method that takes List parameters (instead of ArrayList) is more universal. Thank you all! On 6 Nov 2002 15:07:04 - keiron wrote: + +/** + * Traits for this area stored in a HashMap + */ +protected HashMap props = null; Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: interface instead of implementation
Bertrand Delacretaz wrote: Maybe a minimal best practices or style guide document for developers would be nice, I don't think there is one already? Some time ago Jeremias has promised us that already :) -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: interface instead of implementation
Well, if he needs help getting it done, I'm available. -Original Message- From: Oleg Tkachenko [mailto:olegt;multiconn.com] Sent: Wednesday, November 06, 2002 10:32 AM To: [EMAIL PROTECTED] Subject: Re: interface instead of implementation Bertrand Delacretaz wrote: Maybe a minimal best practices or style guide document for developers would be nice, I don't think there is one already? Some time ago Jeremias has promised us that already :) -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: interface instead of implementation
Hey, Rhett, that would be cool. But it involves reading through that whole discussion again, trying to find a common line and distill that into a nice little document. As I've said, I'll have time to do it, just not now. If you take it, THANKS A LOT! On Wed, 6 Nov 2002 10:37:12 -0500 Rhett Aultman wrote: Well, if he needs help getting it done, I'm available. -Original Message- From: Oleg Tkachenko [mailto:olegt;multiconn.com] Sent: Wednesday, November 06, 2002 10:32 AM To: [EMAIL PROTECTED] Subject: Re: interface instead of implementation Bertrand Delacretaz wrote: Maybe a minimal best practices or style guide document for developers would be nice, I don't think there is one already? Some time ago Jeremias has promised us that already :) I know, I know. :-) See my other mail. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: interface instead of implementation
Sorry, Keiron, for explicitly mentioning you. I was just working in the maint branch seeing all those ArrayLists (former Vectors) and HashMaps (former Hashtables) that are creeping through all the code. And then your CVS commit came... I know I can be an elephant in a porcelaine store sometimes. Sorry. Anyway, I intend to overtake you with style error fixing soon. :-) On 06 Nov 2002 16:43:06 +0100 Keiron Liddle wrote: Since I have removed over 3000 style errors you give me a bit of slack!! :) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: interface instead of implementation
Jeremias, I have no objection at all, as long as it costs nothing. It is free, isn't it? Peter Jeremias Maerki wrote: Fellow FOP developers, would you mind using the interface instead of the implementation where possible? Map instead of HashMap, List instead of ArrayList. I've seen this habit in a number of places and not only by Keiron! I've made it a habit to follow this pattern ... -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
