Why include static members within a primarily non-static class?

Question

I'm having trouble understanding what the over-arching principle is for including static members in a class which normally acts as a blueprint for instantiation. I'll use an example:

Say you have Car class.

Class Car
{
  public int yearBuilt;
  public string make;
  //etc
}

which is principally used to produce new cars. So you have a bunch of non-static members for this, as expected and shown above. Now, say you instantiate 2 new cars as follows

Car.newCar1 = new Car();
Car.newCar2 = new Car();

Now, lets say you have a situation where you want to assign/track the supplier for the newCar's being made today. Assuming you can only have a single supplier at any one time, you figure all newCar's made at this time should share the value, so you add to the Car class:

public static string supplier = "American AutoCompany X";

I can't now access it via the instance, IE: newCar1.supplier, else it would change the value for newCar2 (which in this context is OK and preferable), and instead would have to do this to accomplish the same goal:

Car.supplier;

I don't understand the point of this. Why not just keep your static methods/fields, etc in a completely different class like:

class AllStaticStuff
{
}

and access it from there? Organizationally that may even be preferable, since static members have nothing to do with instantiation anyhow. Or am I missing something fundamental that makes this method of organization more trouble than its worth? I guess the reason I don't like the idea of including statics in a non-static class is that I try to avoid unnecessarily growing membership in any one class as, for readabilities sake, I find it cleaner.

Answer 1

It just depends on the abstraction you are trying to create with your code, really.

If you create a class with the data that you expect to share among all instances of another class, you will have to make that class static anyways. Sometimes it's just cleaner to create a static member.

I think that your example with the car is not a very good one because it wouldn't make sense for cars to have a Supplier property unless the supplier could vary among instances.

A better example, I think, would be to keep a static member that holds a counter. Imagine if you are keeping track of how many instances of a class you have open. Each time an instance is created, the counter increments. All instances of the class need to know this number. It is only relevant to this class, so why create a separate class just for counter data?

Car.Counter makes more sense logically to a human than AllStaticStuff.Counter. It's more obvious.

Answer 2

I like to think of static members as operations (plenty of other uses) but lets say you have your car objects but you need to do something like grab an image of a car (whatever year and make doesn't matter, it can find it), you could do something like this.

Class Car
{
   public int yearBuilt;
   public string make;

   public static string GetImageOfCar(Car c)
   {
     // File operations to find the correct image on the drive and return its path as a string   
     // use c.yearBuilt somewhere 
     // use c.make somewhere
   }
}

Then outside of the class, when you instantiate a car object, you could do this:

Car aCar = new Car();
aCar.yearBuild = 1983;
aCar.make = "Ford Truck";

MessageBox.Show(Car.GetImageOfCar(aCar)); // Would return the path to the image

As far as your supplier name goes, I'd just make that another field that belongs to each object because each car "technically" could have a seperate supplier. I guess you could make a constant or something but you still want some sort of field to identify it easily for each object I would think. You could simply make a static field and use that value outside the class whenever you want it too. In the Car class you'd put something like:

public static string Supplier = "name of supplier";

then access it outside the class using:

MessageBox.Show(Car.Supplier);