Containing Object Design

Question

I'm trying to design a class in an object oriented way and not seeing any great options.

I have a containing object that needs to contain a list of values.
So each row in the containing object could be viewed as a List.
The number of columns of that containing object might be different.

I'm not sure how to design a class that is a List than can support a different options of columns.
Based on certain parameters, the class might have x4 columns of data, in other cases it might have more or less.

Generally just looking for some design guidance on objects that hold variable amounts of data (not list length but almost list type, see the code provided below if my image doesn't make too much sense)

I tried making a containing object which held a list of an abstract base class.

The thing that I didn't like about this approach is that I had to make a concrete class for each type of combination that could be encompassed (the number of columns in my picture), so EntryCombo A has 4 values (because it would have 4 columns. EntryCombo B has only 2 values because it has 4 columns.

I'm basically wondering if there is a better way to do this such that I don't need to know each combination or type.

public class ContainingObject<TEntryType> where TEntryType : Entries
{
    public List<TEntryType> RowEntries { get; } = new List<TEntryType>();
}

public abstract class Entries
{
    // Base Class
}

public class EntryComboA : Entries
{
    public int ValueA { get; set; }
    public int ValueB { get; set; }

    public int ValueC { get; set; }
    public int ValueD { get; set; }
}

public class EntryComboB : Entries
{
    public int ValueA { get; set; }
    public int ValueB { get; set; }
}

Answer 1

Without more information, it's hardly possible to give a definite answer. There's no a one-size-fits-all answer. On one extreme of the spectrum, you can model any database row as a dictionary. The column name is the key, and the dictionary value for that key is the row's column value.

At the other extreme, you could use the Visitor pattern to model that each row is one of n subtypes, where n is fixed and all subtypes are known at compile time.

A good design involves understanding the trade-offs involved and picking a place somewhere on that spectrum between dictionary and Visitor.