A dictionary with a built-in factory?

I have a solution that works, but for educational purposes I want to understand if there is a better/cleaner/right way to do it.

Problem: In my "client" app I have a dictionary Dictionary<String, PremiseObject> where the key (String) is a immutable URL to a resource (it's actually a REST URL). PremiseObject is the base type of a whole set of derived classes; thus the Dictionary actually contains a family of classes all derived from PremiseObject.

A key requirement is I want to try to 'guarantee' that no PremiseObjects get created OUTSIDE of the dictionary.

Solution: I have the following function for getting a object out of the dictionary. It either accesses the existing instance, or if it does not exist creates it:

public PremiseObject GetOrCreateServerObject(string premiseObjectType, string location)
{
    PremiseObject po = null;
    if (!premiseObjects.TryGetValue(location, out po))
    {
        string classname;
        // Create an instance of the right PremiseObject derived class:
        po = // gobbly-gook that is not relevant to this question.
        premiseObjects.Add(location, po);
    }
    else
    {
        Debug.WriteLine("Already exists: {0}", location);
    }
    return po;
}

Callers do this:

DoorSensor door = 
         (DoorSensor)server.GetOrCreateServerObject("DoorSensor", 
                                                    "http://xyz/FrontDoor");

Works great. But I think there's a pattern or design that would elegantly allow me to encapsulate the "single-instance of each object contained in the dictionary" more.

For example, callers could do this:

DoorSensor door = null;
if (!server.ServerObjects.TryGetValue("DoorSensor",
                                      "http://xyz/FrontDoor", 
                                      out door))
    Debug.WriteLine("Something went very wrong");

I'm not really what to call this pattern. My ServerObjects are "single-instanced" by location. And my GetOrCreateServerObject is like a factory that lazy creates.

But it's possible for instances to be created that don't get put into the dictionary, which could lead to problems.

Like I said, what I have works... Cheers!

UPDATE 1/26/2011 10:13PM - I just realized a potential problem: On the server side the object represented by a location/URL can actually be multi-inherited. It is THEORETICALLY possible for an object to be both a DoorSensor and an DigitalRelay.

I currently don't care about any of those cases (e.g. for garage doors I simplified my example above; there really is no DoorSensor I exposed, just a GarageDoorOpener which includes BOTH properties for sensing (e.g. Status) and actuation (e.g. Trigger). But this puts a wrinkle in my whole scheme if I wer开发者_如何学编程e to care. Since this project is just for me :-) I am going to declare I don't care and document it.

I would propose the following simple idea:

1. PremiseObject's constructor is declared internal.
2. A special factory object is responsible for creating (or returning an already created) instances. The dictionary is a part of the factory.
3. Clients are located in another assembly.

This way PremiseObjects can be created by clients only through the factory. This way you can guarantee that only single instance of object exists for each location.

A variant of the idea would be to declare the PremiseObject's constructor private, and declare the factory a friend; but (unlike C++) C# doesn't have a friend notion.

Ok you can probably avoid a parameter and a cast (in the consumer code any way) with a generic method.

public abstract class PremiseObject
{
    protected PremiseObject()
    {

    }

    public string Location { get; set; }

    public static void GetSensor<T>(string location, out T sensor)
             where T : PremiseObject, new()
    {
        PremiseObject so;
        if(_locationSingltons.TryGetValue(location, out so))
        {
            sensor = (T) so; // this will throw and exception if the 
            // wrong type has been created. 
            return;
        }
        sensor = new T();
        sensor.Location = location;
        _locationSingltons.Add(location, sensor);
    }

    private static Dictionary<string, PremiseObject> _locationSingltons 
             = new Dictionary<string, PremiseObject>();
}

Then the calling code looks a bit nicer:

    DoorSensor frontDoor;
    PremiseObject.GetSensor("http://FrontDoor/etc", out frontDoor);

So I like that calling convention - if you want to stay away from throwing an exception you can change the return type to bool and indicate failure that way. Personally I wouls say that an exception is what you want.

You may prefer the call without the out parameter - but if you do that then you have to supply the type to the method call - anyway defining the factory method would look like this:

public static T GetSensor<T>(string location) where T : PremiseObject, new()
{
    PremiseObject so;
    if (_locationSingltons.TryGetValue(location, out so))
    {
        return (T)so; // this will throw and exception if the 
        // wrong type has been created. 

    }
    T result = new T();
    result.Location = location;
    _locationSingltons.Add(location, result);
    return result;
}

Then the calling code looks like this:

var frontDoor2 = PremiseObject.GetSensor<DoorSensor>("http://FrontDoor/etc");

I like both these approaches because nothing has to be repeated. The type of the PremiseObject only gets stated once - there is no need for a string defining the type.

If you want to be really, really sure that no instances of PremiseObject get created that aren't placed in the dictionary, you could make the constructors all private, and create a static constructor (for each subclass) that took as a parameter the Dictionary object you're referring to. This static constructor would check the dictionary object to make sure that there wasn't an existing instance, and then return either the new or the existing instance as required. So something like this:

public class PremiseObject
{
    public static Dictionary<string, PremiseObject> PremiseObjects { get; private set; }

    static PremiseObject()
    {
        PremiseObjects = new Dictionary<string, PremiseObject>();
    }
}

public class DerivedPremiseObject : PremiseObject
{
    private DerivedPremiseObject()
    {
    }

    public static DerivedPremiseObject GetDerivedPremiseObject(string location)
    {
        DerivedPremiseObject po = null;
        if (!PremiseObject.PremiseObjects.TryGetValue(location, out po))
        {
            po = new DerivedPremiseObject();
            PremiseObject.PremiseObjects.Add(location, po);
         }
        return po;
    }
}

And there are a variety of similar strategies you could use. The key is to somehow make the constructor private and only allow access to the constructor through a static method that enforces the logic of the class construction.

Perhaps you could make PremiseObject a singleton, then you wouldn't have to worry about each object in the dictionary beign a single instance?

In the general case, setting access modifiers on your constructors should do the trick of not allowing anyone external to create the objects (barring reflection). However, these would need to be internal, so anything else in the assembly would be able to instantiate them.

I suspect many of your requirements may be met by using an off the shelf dependency injection container that supports singleton instances. It feels close, but maybe not quite the same. (possibly StrutureMap, Ninject, Castle Windsor, or Unity in no particular order)