[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Duplicate object prevention policy
From: |
Mark Wielaard |
Subject: |
Re: Duplicate object prevention policy |
Date: |
Sat, 03 Dec 2005 21:52:38 +0100 |
Hi Jan,
On Wed, 2005-11-30 at 02:58 +0100, Jan Röhrich wrote:
> imagine the following case: A method supports the lookup of objects
> using a name -> object mapping. The objects are stored in a map but can
> easily be newly created instead of performing a real lookup. Shall we
> perform this real lookup even if the newly created object is equal to
> the original object in terms of Object.equals().
That really depends on how much such a method is called, and how many
different objects can be returned. If there are not that many object
then you should probably store them in a map. If there are not many
calls then it probably is not worth it to cache it, especially if
recreating an instance is relatively cheap.
> Concrete?: Have a look at
> java.awt.datatransfer.SystemFlavorMap#decodeDataFlavor(). This is only
> one appearance of this problem (out of many many).
In this case I would just create the new DataFlavor since it seems this
is relative cheap and the method doesn't look like it will be that often
called. If later benchmarks on real applications show otherwise we can
always think about a caching mechanism.
Cheers,
Mark
signature.asc
Description: This is a digitally signed message part