commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Schofield" <>
Subject Re: [chain] CatalogFactoryBase
Date Mon, 18 Oct 2004 14:48:50 GMT
Craig McClanahan wrote:

>I prefer to use them throughout, so we have the opportunity to not synchronize in cases
where thread safety is not an issue -- it is here, though.
OK makes sense.

>More subtly, though, you'll also note that I use Map instead of
>HashMap to declare the actual instance variable, and the return values
>from appropriate methods.  That way, the actual implementation class
>could be specialized later without breaking method signatures.  That's
>not as easy to do if you're throwing Hashtables around (any
>specialized version would have to subclass Hashtable, and not some
>more generic interface).
This makes sense in general but I don't see how it applies in this 
specific case.  Only the instance variable is a Map.  There aren't any 
public methods in CatalogFactory that return Map so how does this help 
with subclassing?  I'm just wondering ... I'm not proposing changing it 

Finally, I also just noticed that you implemented getInstance() in 
CatalogFactory and had it return an instance of CatalogBase.  Did you 
change your mind on this?  Is this because it will be easier to manage 
class loader issues in the factory?

I'm assuming that your reasoning for having CatalogFactoryBase is so 
that we (or end user) can change the implementation of CatalogFactory 
without affecting users code.  Right now user's can't really specify 
their own CatalogFactory.  I'm fine with this, but just checking to see 
if this was your reasoning.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message