`Static inheritance` pattern

I have an abstract class Entity in my code, which requires a reference to an instance of EntityData to operate. (EntityData provides basic information about the type of the entity).

In the design of my program, every type of entity would have its own class that extends Entity, and thus would have to provide EntityData that would describe and be shared between all of the instances of that that entity class.

EntityData itself is an immutable class that is built like a multiton (similar to Java's enum). It has a private constructor, and its instances are revealed as readonly static fields.

An example of how EntityData would look:

sealed class EntityData
{
    public static readonly EntityData Table = new EntityData(250, 60);
    public static readonly EntityData Chair = new EntityData(120, 25);

    public readonly int Cost;
    public readonly int Weight;

    private EntityData(int cost, int weight)
    {
        Weight = weight;
        Cost = cost;
    }
}

I can think of two simple ways to deal with this, but I am uncertain which one I should go with.

First one is to add a reaodnly field to Entity and request is via the constructor, so Entity would look like this:

abstract class Entity
{
    private readonly EntityData data;

    protected Entity(EntityData data)
    {
        this.data = data;
    }
}

While an extending class, Table for example, would look like this:

sealed class Table: Entity
{
    public Table() : base(EntityData.Table) {}
}

The second option would be to add an abstract, protected property (getter only) to Entity. In this case Entity would look like this:

abstract class Entity
{
    protected abstract EntityData Data { get; }
}

While the extending class Table would look like this:

sealed class Table : Entity
{
    protected override EntityData Data
    {
        get { return EntityData.Table; }
    }
}

Thus internally, Entity would simply use the property instead o

I think I personally like the set by constructor method in general. I think it provides a means by which you can better allow for TDD and also implicitly implies the contract all inheriting classes must obey in providing a Entity object if they wish to inherit from the base class.

I think if I were going make Entity a requirement of the second method I would make the protected method abstract which would also enforce this constraint. However that doesn't allow for the easy of use in using dependency injection which I think would suit this approach nicely.

I'm not sure why there would be a huge increase in the size of the Entity object itself. I would assume the size increase would only be as large as the size of the memory register holding the location of the Entity object itself. As for performance, I can't comment explicitly but I would assume you would still need to make visible the EntityData object to it's children so you would probably do that via a property accessor or method anyway so performance impacts to me would be low on the priority list unless profiling the code suggested otherwise.

So assuming the Entity is required in inherited classes I would consider something like:

abstract class Entity
{
    protected EntityData Data { get; private set; }

    protected Entity(EntityData data)
    {
        this.Data = data;
    }
}

StackExchange Code Review Q#13420, answer score: 2