Qfyilyi

I found an inheritance tree in our (rather large) code base that goes something like this:

public class NamedEntity

{

    public int Id { get; set; }

    public string Name { get; set; }

}



public class OrderDateInfo : NamedEntity { }

From what I could gather, this is primarily used to bind stuff on front-end.

For me, this makes sense as it gives a concrete name to the class, instead of relying on the generic NamedEntity. On the other hand, there is a number of such classes that simply have no additional properties.

Are there any downsides to this approach?

This is my favorite use of inheritance. I use it mostly for exceptions that could use better, more specific, names

The usual issue of inheritance leading to long chains and causing the yo-yo problem doesn't apply here since there is nothing to motivate you to chain.

This is something that I use to prevent polymorphism from being used. Say you have 15 different classes that have NamedEntity as a base class somewhere in their inheritance chain and you are writing a new method that is only applicable to OrderDateInfo. You could just write the signature as void MyMethodThatShouldOnlyTakeOrderDateInfos(NamedEntity foo) and hope and pray no one abuses the type system to shove a FooBazNamedEntity in there. Or you could just write void MyMethod(OrderDateInfo foo). Now that is enforced by the compiler. Simple, elegant and doesn't rely on people not making mistakes.

Also, as @candied_orange pointed out, exceptions are a great case of this. Very rarely (and I mean very, very, very rarely) do you ever want to catch everything with catch (Exception e). More likely you want to catch a SqlException or a FileNotFoundException or a custom exception for your application. Those classes often times don't provide any more data or functionality than the base Exception class, but they allow you to differentiate what they represent without having to inspect them and check a type field or search for specific text.

Overall, it's a trick to get the type system to allow you to use a narrower set of types than you could if you used a base class. I mean, you could define all your variables and arguments as having the type Object, but that would just make your job harder, wouldn't it?