Is this physical collection class that contains only static methods an Anti-Pattern?

Question

I'm trying to figure out if I should continue on with a current pattern in an application I'm working in, or refactor this into something else.

I have a set of collection classes off a generic base of List. These classes have public constructors but contain only static methods that return collections. They look like this:

public class UserObjCollection : BaseCollection<UserObj>
{
  public static UserObjCollection GetAllUserObj()
  {
    UserObjCollection obj = new UserObjCollection();
    obj.MapObjects(new UserObjDataService().GetAllUserObj());
    return obj;
  }
}

Is this a Pattern or Anti-Pattern and what are the merits of this over a straight factory pattern?

EDIT: I'm leaning towards removing these physical collections, and moving their static methods into the data access layer (UserObjDataService). There are a lot of object types so I need to keep the code in seprate places, but they almost all have a 1 to 1 factory object in the datalayer.

Answer 1

I tend to call this factory method pattern (possibly incorrectly).

Because I am doing only Test Driven Development these days, I tend to avoid it, because it is very difficult to test. In your static method you create a lot of concrete classes, so you can't really mock any of these objects. Moreover you can't mock the whole static method either, which makes all the classes fairly tightly coupled. A straight factory patterns would at least allow to mock the whole factory object, which makes testing much easier.

Answer 2

UserObjCollection does not add anything to BaseCollection<UserObj>, objects of both classes are identical, functionality wise. It would be nicer to remove UserObjCollection and put GetAllUserObj() in BaseCollection<T> (Factory Method). You can also put GetAllUserObj() in a seperate static class. I don't think the abstract factory pattern is necessary here, as you're not creating different object families.

The reason why I would remove UserObjCollection is because this class might cause other developers to add to it without thinking it through. If it later turns out that UserObjCollection is in fact sufficiently different from BaseCollection<UserObj> that it warrants a separate class, you can re-add UserObjCollection then.