1

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).

  • The statement that (non-constant) properties of different instances must have the same value triggers a warning signal in me. It is extremely unusual that if you change property A in instance X, that then the same property in other instances also must change. I would urge you to check that those properties really must always the same for all instances, or if they just accidentally happen to have the same value now. – Bart van Ingen Schenau Nov 18 '18 at 10:22
  • Good. I added better examples that really would never (rarely) vary. Title (easy enough to repeat if needed), but Description you wouldn't want to copy the class description into every instance. – goodeye Nov 18 '18 at 18:18
  • "Title" and "Description" in a "catalog section" are generally not concerns of the item itself => they belong to a different class. Also, the price may change without a change to the item proper => might also be a different class. – Bernhard Hiller Nov 19 '18 at 10:32
2

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.

  • The current problem has separate classes, that really wouldn't extend. It's like there are Baseball and Apple classes. I edited the question for better examples of the common properties Title and Description. I'll look into composition, thanks. – goodeye Nov 18 '18 at 18:20
  • 1
    If you make a catalogue, you shouldn't go for having every catalog section having its own class, because 1) this will require coding for extending the catalogue 2) this assumes some pricing strategies that might evolve over time. This is exactly why the game industry goes for entity component system rather than deep, specialised, class hierarchies. – Christophe Nov 18 '18 at 20:09
  • @goodeye Another question: did you consider doint it the othe way round ? I.e. havein catalogue items with prices, linked to a family of article variants (e.g. color, size for tee shirts, color logo for baseballs, etc...) ? – Christophe Nov 18 '18 at 20:11
  • Those are great notes, thanks. I think your overall ideas are right, so I'll chew on this. It does seem like something needs to "flip around", either with composition or a common item definition of some sort. – goodeye Nov 18 '18 at 20:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.