I voted for codingoutloud answer and I'd like to expand on it a little.
Wrapping collections in classes is something I've come to try to always do--my rule is "Never pass a naked collection". The biggest failures of OO I've seen is when people are afraid to add methods where they belong. In your case the methods belong on the collection (Totally obviously if you think about it), so put them there by wrapping the collection, and to put the icing on the cake, only expose the functionality you need outside your new class (as codingoutloud did) so that you can look at your single, small class and easily understand everything manipulating that collection.
You don't have to solve every possible problem because it's all your code, you can edit the collection wrapper just as easily as you can edit the other classes that interact with it. This lets you pull other code into the class as necessary--if you don't ever expose the collection it will become quickly obvious what code belongs in the wrapper.
This also gives you complete control over the collection so you can prevent it from getting into a state inconsistant with it's function (For instance, if no entry in the collection can be null, just prevent anyone from putting a null in!)
Most of the bad OO code I've ever seen has been created because someone chose to write static utilities or inline code that belonged in objects they couldn't add code to instead of wrapping the offending objects in code of their own that they could modify.