Question

I’m trying to build a set of reusable EF models and interfaces. One such interface is called ICategorised, and looks as follows:

public interface ICategorised {
    int CategoryID { get; set; }
    Category Category { get; set; }
}

And here’s what the Category object looks like:

public class Category {
    public int CategoryID { get; set; }
    public string Title { get; set; }
    public Type Type { get; set; } // Is 'Type' the wrong type for this?
    public string Description { get; set; }
}

I quite like the principle of this but I’m slightly stumped on how best to get and set the Type for any object which implements ICategorised. My end goal is the ability to create an object such as:

public class Car : ICategorised {
    public int CarID { get; set; }
    public string CarName { get; set; }
    public int CategoryID { get; set; }
    public Category Category { get; set; }
}

.. and somehow be able to query Categories where Type==Car.

Answer 1

I think you should reconsider the current usage of ICategorized as the Existential Type. It seems to me that actually this should be Category, because Category provides definitions for everything in ICategorized but doesn’t actually implement it at present. If you want to keep ICategorized I would make Category implement it as a first point.

Secondly, I would make Category abstract because it shouldn’t be instantiated directly. Then your Car and any other categorized class you create will derive directly from the abstract Category. This makes them ICategorized inherently too if you change your hierarchy as noted above.

That would achieve what you are after I think, and lead to a cleaner hierarchy that is extensible for future types. You can then query on Type directly as each specific Category subclass will have an explicit Type set, such as Car.

Hope that helps, or at least is a step in the right direction.