Design pattern for common properties: static properties or a separate single instance class?

Question

I need to create properties that have values common to instances of a class. I'm unsure how to solve this problem, so I could use some help. (This is in C#, but isn't a language-specific question.)

I've been reading about single instances (not a singleton), static properties, and other patterns This question is close, but the one answer discusses the data implementation, not the code. Splitting object definitions (catalog) from instances (physical objects)

I have classes that are used as a list of instances, e.g., catalog of products that have different features like a Baseball. These instances contain the properties that vary, e.g., Color, Logo.

public class Baseball
{
    public int ID { get; set; }

    public Color Color { get; set; }

    public string Logo { get; set; }
}

// Catalog code listing the baseballs
List<Baseball> Baseballs = ...

I need to create properties that have values common to all the instances. These don't vary among the instances, but will be in the database, so they aren't constants. e.g., they all have the same price and size.

public decimal Price { get; set; }

public int Size { get; set; }

I don't know where to put these. They're not really Type descriptors in the code, describing the Baseball class for programmers. The values will be in the database, so they're not constants. The data is common to all instances of Baseball, but not other classes, so this isn't a case of extending a base class from Ball.

EDIT with better example

Price and Size are certainly properties that typically vary with products, so they weren't the best examples. The case for this is section heading content, that you'd see at the top of the catalog section. e.g., Title ("Baseballs"), and a Description ("These are great baseballs").

Static properties

I've seen some static property examples, but they're mostly used for state, not common data. They also tend to be discouraged as a type of global variable. My guess is it would look something like this, but this doesn't feel right:

public class Baseball
{
    public int ID { get; set; }

    public Color Color { get; set; }

    public string Logo { get; set; }

    public static decimal Price { get; set; }

    public static int Size { get; set; }
}

Separate class

I'm a big fan of Active Record, so that's how these instance classes are implemented. I tend to lean toward creating a new BaseballType or BaseballDefinition or BaseballCommon class, and creating one instance. But, this doesn't inherently enforce one instance.

public class BaseballCommon
{
    public decimal Price { get; set; }

    public int Size { get; set; }
}

Data

Related to this, I'm trying to separate thinking about the database implementation, so it doesn't drive the class decision. So even if separate "common" classes are the answer, I don't have to create a bunch of one-record Active Record tables. Perhaps a table of name/value records for each class and property. I'm also curious what that pattern might be? (or this may be a separate question after this one is answered).

Answer 1

The first thing that comes to my mind is that your classes might be over-specialized:

• Carefully consider, if you really need a Baseball class, or if a Ball class would not extend the usage of your class (after all a football could also be sold with different colors and logos, but also at a different price). Perhaps the class Item would be even more general.
• If you're in doubt, use composition rather than static. Static would require balls of different prices be in different classes. SO if your shop owner would one day decide to have premium items at higher prices, you'd need to change the code and create a PremiumBaseball and StandardBaseball class. If you'd use composition, you could still share prices for a family of products, but you wouldn't need to change fundamentally your code.

Of course, if all this was only an hypothetical example class for a much simpler problem, and if the class and the commonality are well defined and would for sure never evolve, then the static could be an (inflexible) alternative.