Question: While checking out the generic collection in .net i found about KeyedByTypeCollection. Although I worked with it and got to know how to use it, I did not get in which scenario it will be useful.

I read through [ServiceProvider, cache etc. done with generics without cast](https://stackoverflow.com/questions/178255/serviceprovider-cache-etc-done-with-generics-without-cast), but could not get much.

I think, there must have a reason as to why it has been included in the .Net framework. Any body who have used the KeyedByTypeCollection can explain me why they used it or any body, if they know in which scenario potentially it can be used, can explain it to me. 

As more of a curiosity does any other languages support this type of collection ?

Answer: 
AFAIK, this generic collection serves just as a simple wrapper for `KeyedCollection<KEY,VALUE>` when `KEY` is the Type of the `VALUE` to store.

For example, it is very convinient to use this collection if you want to implement a factory returning singletons:

```
public class Factory<T>
{
    private readonly KeyedByTypeCollection<T> _singletons = new KeyedByTypeCollection<T>();

    public V GetSingleton<V>() where V : T, new()
    {
        if (!_singletons.Contains(typeof(V)))
        {
            _singletons.Add(new V());
        }
        return (V)_singletons[typeof(V)];
    }
}

```

The use of this simple factory would be something like the following:

```
    [Test]
    public void Returns_Singletons()
    {
        Factory<ICar> factory = new Factory<ICar>();
        Opel opel1 = factory.GetSingleton<Opel>();
        Opel opel2 = factory.GetSingleton<Opel>();

        Assert.IsNotNull(opel1);
        Assert.IsNotNull(opel2);
        Assert.AreEqual(opel1, opel2);
    }

```

Another usage for `KeyedByTypeCollection<T>` would be inside a service locator...
The "singleton factory" is a different approach to the problem of singletons.

There are three main approaches:

1. Implement a `Current` or `Instance` property in every class - means a lot of repeated code. Which is bad.
2. Implement a `Singleton<T>` base class - means you can have `class A : Singleton<B>` which is clearly wrong.
3. Implement a `SingletonFactory` - this is well documented. I thought it up about 12 months ago and was frankly surprised to find it to be a very well covered subject in the Java world. The one I've written for my current client has no interface restrictions, and is static, which means it has a lock around the collection for thread safety. Without making it static, you risk getting two singletons of the same type that are different objects.