Question

This is a bit of weird scenario. I had a class that was quickly becoming a God class. It was doing WAY too much. Suddenly I had violated SRP. The class was responsible for X and Y and Z, oh and A, and B, don’t forget C. So I decided to refactor it. The reason it got this big is because the class does a lot of work with a collection which I have done a lot of work to synchronize the access to it because it is a multi-threaded system using ReaderWriterLockSlim.

So I identified the main responsibilities. There is a part that feeds the collection. Occasionally it might need to make a new element in the collection. I have an object that cleans out the collection on a timer. So when the timer elapses I look for elements that can be removed from the collection. Then I have an object which needs to fetch stuff from the collection. It needs to ask each item in the collection for stuff so it needs to iterate.

Previously the object was doing all of this itself. Easy to manage in terms of locking. Not so easy to Unit test. Too much going on, too much mocking. It was just nasty. Breaking it out into parts makes unit testing much easier BUT it makes the locking much harder.

So each part, the feeder, the cleaner and the retriever all need an instance of this object. So I should inject it in the constructor and then I can mock it out and testing is easy. But now because the collection is shared amongst many objects I cannot give each one direct access to it. I need to provide a sort of synchronization wrapper.

I was thinking that when the feeder asks for a new item in the collection, the wrapper locks the collection, creates a new item, gives it to the feeder and notifies the cleaner that there is a new item in the collection. The cleaner adds that item to its copy of the collection.

When the cleaner runs, it runs through its version of the collection, when it finds something that can be removed it removes it from its collection and informs the wrapper and the wrapper notifies the feeder who takes it out of his collection. The retriever uses a foreach loop. So the wrapper can implement IEnumerator and IDispose. Then when the enumerator is created I can lock the collection and when it is disposed I can exit the lock.

1. Is there a design pattern for what I am trying to do?
2. Is there a better way to do this?
3. What is a good name for this wrapper?

I thought of the following:

• Provider (But it does more than just provide)
• Maintainer (A bit vague)
• Synchronizer (I like this one the most)

Answer 1

I think your idea of a Provider, Maintainer and Synchronizer sound just fine… I’m not aware of an out-of-the-box design patter for this situation, so yours seems reasonable.

Now the part that I think I can help you with is the iteration. First and foremost, you will have to create a wrapper for your collection. The wrapper will simply wrap all the standard methods of the collection. For example:

public void Add(Object obj)
{
    lock(sync)
    {
        _collection.Add(obj);
    }
}

Second, if you want to lock the enumerator you follow this example.

I don’t like the idea of letting the garbage collector decide when to unlock the synchronization object, so in my personal opinion I would rather do it in an optimistic way:
1. Copy each element in the collection into a new collection.
2. Return that enumerator of the new collection.
3. When iterating over the enumerator do all of my modifications on the original collection.

Here is the example:

// In your Collection wrapper you need to provide an enumerable copy:
public IEnumerator<T> GetEnumerator()
{
    lock(sync)
    {
        Collection copy = new Collection():
        foreach(Object element in collection)
        {
            copy.Add(element);
        }

        return copy.GetEnumerator();
    }
}


// In your Maintainer's cleanup method you will do the following:
public void TimedCleanup()
{

    // You don't have any contention on the original collection.
    foreach(Object element in originalCollection)
    {
        if(shouldDeleteElement)
        {
            // Not a problem if somebody already iterated over
            // the collection and removed the same element.     
            originalColection.Remove(element);
        }
    }
}

I hope it answers your question :).