Not at all, Rick.  It looks like an excellent
implementation of Singletons.

Very clean, and looks pretty threadsafe to me, at least
in the access of the instance.  However, you'll want to
make sure any operations on "items" are threadsafe...

Did you say that the collection only gets written once?

In either case, Collections by nature are NOT
synchronized automagically.

Check out the stuff in here on forcing threadsafe
collections:
http://java.sun.com/j2se/1.4.1/docs/api/java/util/ArrayList.html

Good luck.

Duffer

Rick Reumann wrote:

> 
> 
> I have a couple books on design patterns but I'm still
> a bit stumped on
> how to 'best' handle this situation...
> 
> For the sake of explaining this I'm using an example
of
> "Stores." The
> example of stores isn't perfect but it's easier to
> picture than my real
> life example. 
> 
> What I want to be able to is pull out a List of
"items"
> from a Store
> object that will never change for the life of the web
> application (I
> know in real life this wouldn't be the case for Store
> items). Then I
> also have subclasses of Store - "Target" and "Walmart"
> - where I need to
> pull out a List of "specials" and these unique Lists
> for Walmart and
> Target will not change for those subclasses.
> 
> Now each of the above classes only needs to be
> instantiated once so they
> can be all singletons and the Lists only need to be
> populated once. It
> gets a bit tricky since the creation of the object
> instances need to be
> thread safe and you can't really make the superclass
> (Store) a singleton
> if you plan to subclass it. So what I've done is
this...
> 
> 
> public abstract class Store {
>     
>     private static Collection items = null;
>     private Collection specials = null;
>     
>      static {
>         if ( items == null ) {
>             synchronized( Store.class) {
>                 if ( items == null ) {
>                     items = //get List of Items from
> somewhere
>                 }
>             }
>         }
>     }
>      
>     public static Collection getItems() {
>         return items;
>     }
>     public Collection getSpecials() {
>         return specials;
>     }
> }
> 
> 
> public class Walmart extends Store {
> 
>     static private Target _instance;
>     
>     private Walmart() {
>         specials = //get specials unique for Walmart
>     } 
>     
>     public static Walmart getInstance() {
>       if (_instance == null) {
>         synchronized(Walmart.class) {
>           if (_instance == null) {
>             _instance = new Walmart();
>           }
>         }
>       }
>       return _instance;
>     }
> }
> 
> public class Target extends Store {
>     //same thing like above but gets specials unique
> for Target
> }
> 
> What I then have is a factory that figures out what
> Store to give me so
> in my code I can just call:
> 
> Store s = SomeFactory.getStore() //and SomeFactory
> returns to me the
> correct type of store.
> 
> The above seems to work ok, but is it a crappy design
> and are there
> still some multithreading issues that could screw
> things up?
> 
> Thanks,
> 
> -- 
> Rick Reumann
> 
> ---
> You are currently subscribed to jdjlist as:
> [EMAIL PROTECTED]
> To unsubscribe send a blank email to
> [EMAIL PROTECTED]
> <a
href="http://mail.duffhome.com/jump/http://www.sys-con.com/fusetalk";>http://www.sys-con.com/fusetalk</a>

---
You are currently subscribed to jdjlist as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
http://www.sys-con.com/fusetalk

Reply via email to