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, 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 ?
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:
Implement a Current
or Instance
property in every class - means a lot of repeated code. Which is bad.
Implement a Singleton<T>
base class - means you can have class A : Singleton<B>
which is clearly wrong.
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.
In analyzing this class, my take is that it is totally irrelevant. Use the base class KeyedCollection
and write the GetKeyForItem
method to return the Type of the Item parameter.
There are four methods defined on the KeyedByTypeCollection
that are irrelevant (Find
, FindAll
, Remove
, and RemoveAll
). Find, FindAll, and RemoveAll have no base KeyedCollection
implementations. Remove does exist in the base class.
The first problem with all four of these methods in the KeyedByTypeCollection
is that they perform a serial search of the base Collection to find the item(s). Why not just use the indexer from KeyedCollection
to retrieve the appropriate item?
Second, FindAll
and RemoveAll
will only ever find 1 item (if one exists in the Collection) - because BY DEFINITION, only one item of the specified Type will exist in the Collection (oh, and FindAll
will serially read through all the elements in the Collection, even if it finds the matching element at the beginning). So, FindAll
and RemoveAll
will read ALL the items in the Collection before either Finding/Removing 0 or 1 item(s). Again, why not use the indexer or the base version of Remove to perform the required process?
The second problem with the class is that it is not designed to be a base class (in other words, don't inherit from it unless you know how the internals of the methods are written). There are no calls to the GetKeyForItem
method in places where it should be used, so, if you override the GetKeyForItem
method, you must also override several other methods to properly get the key for the Collection.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With