views:

71

answers:

2

I am using a list for particles.

List<Particle> particles;

Normally i place this list in my Simulation class. Which calculates position, velocity and other properties of particles.

A few other classes need this particle data for output and post processing.

is it OK to create a static class,

static class Particles
{
    static List<Particles> plist;
}

to access particle data from other classes?

+2  A: 

I would recommend staying away from static classes/methods whenever possible. They tend to lead to high coupling of code. Although there are some cases where it's far faster to use them (hopefully sparingly).

I'm not quite sure what you are going for from your question, but I would at least recommend changing the static class to expose a property instead of a field.

public static class Particles
{
    public static List<Particles> PList { get; set; }
}

or

public static class Particles
{
    private static List<Particles> _plist;

    public static List<Particles> PList
    {
        get { return _plist; }
        set { _plist = value; }
    }
}

This way you encapsulate the list a little more. For example, you can check for null values during the getter or setter.

Jerod Houghtelling
"They tend to lead to high coupling of code"Yes and what is worse yet is that once you begin to use them they become a slippery slope. They are extremely convenient until all of a sudden they are not then they are a nightmare. In early versions of developing my DAL I hastily made a number of my repositories static, once I switched to using an ORM uncoupling this code has been painful and long. I did it to myself and learned the hard way.
joshlrogers
@Josh Amen! They are way too easy to abuse and after a little while you are facing a God class. The company that I work for has a coding standard to avoid static methods. We've been bitten by their convenience way too many times.
Jerod Houghtelling
A: 

You have at least two options here:

  1. Create an IList<Particles> property in each class that operates on particles.

  2. In each class that operates on particles, create a private IList<Particles> field and a constructor that takes such a list as a parameter.

Either of these options will preserve encapsulation of the list.