views:

81

answers:

5

Here's a specific problem that I run into when creating objects, such as collections, that need to be available through the whole scope of the application.

I have the following class:

 class UserDataCollection
    {
        List<UserData> Collection = new List<UserData>();
        UserData current;

        public UserData Current
        {
            get { return current; }
            set 
            {
                current = value;
            }
        }

        public UserDataCollection( UserData userdata )
        {
            this.current = userdata;
        }

        public void Add ( UserData item )
        {
            Collection.Add(item);
        }


    }

Now for every UserData object I want to add, it's going to create a new List object each time I go UserDataCollection datacoll = new UserDataCollection(userdata);

So my objects will never be added to the same collection, which is not the point of this collection.

Is this then a good singleton case or just create the object at Application Init and use the same object throughout?

What's the best design practice for something like this?

A: 

Collections like this are for multiple objects obviously, so you would instantiate them where you are creating a ... collection of objects... If you want to use a ctor, then it should take as it's parameter a ... collection or enumerable set of those objects...

 // Inheriting from List<UserData> eliminates need for most of your code
 class UserDataCollection: List<UserData>
 {        
      public UserDataCollection(IEnumerable<UserData> users)
      {
          foreach (UserData usr in users)
              Add(usr);
      }  
 }
Charles Bretana
It is a collection I want to keep track of during the course of the applications existence.
Tony
Then you create it in Application's main, when app starts up, and either pass the reference to it around to everywhere you need it, or make it globally accessible (put the single instance of this collection into a static property of some static class)
Charles Bretana
A: 

If there will only ever be one UserDataCollection per application then I don't see why not make it a singleton.

Stan R.
Because singletons are evil.
Jason
Singletons are perfectly rational in situations that warrant them. Blanket statements are evil.
Bryan Ross
Why do you say that. Surely if the underlying logic requirements follow a singleton pattern then a singleton is ideal.
Mongus Pong
@Bryan Ross: Yes, by definition of "situtations that warrant them" your statement that they are perfectly rational in some situations is vacuously true. Singletons expose global state, they are not friendly to unit testing, they violate the single responsibility principle, cause tight coupling and are used in far more situations that don't warrant them then those that do. That makes them evil. And "blanket statements are evil" is trivially false. Evil things are evil. Like singletons.
Jason
+1  A: 

You could just make the list static. Then there will only ever be one collection.

Mongus Pong
Static collections will need a lot more Thread safety code.
Stan R.
then there a property of static object I haven't grasped, could you or someone elaborate?
Tony
@Tony, a static property is like a global variable..it can be accessed by anything at any time, therefore in a multi-threaded application one thread may change the value of the static variable before the other thread. This is called a Race Condition.
Stan R.
True you do need to work to ensure they are thread safe if operating on a multithreaded environment. Only one copy of a static member is kept in memory and all the class instances access this one member. So in this case you have one static list and all the instances of the userDataCollection classes that you create will share this one list.
Mongus Pong
A: 

I like the idea of a Singleton here, if you only want one for your entire application. If you are using this in an ASP.NET application, you will have to watch out with Singletons because static variables are like saving data in Application state...which is probably what you want...but not easily noticeable to the outside world (maintainability issue).

CSharpAtl
+1  A: 

It depends

If it's a web application, you can create your collection on application start and store it into Application property of HttpContext. If not, you can use a singleton or an IoC container and configure it to always return the same instance of the object.

P.S : If multiple threads of the application will run simultaniously, by sure to use a lock before updating the collection.

Hope it will help.

mberube.Net
You need to lock when accessing the list as well as updating as you don't want a list you are iterating through to be updated halfway through.
Mongus Pong