Is there a way to strongly type integer ID values in C#?
I’ve recently been playing with Haskell and can immediately see the advantages of its strong typing when applied to ID values, for example you would never want to use a PersonId in place of a ProductId.
Is there a nice way to create an Id class/struct that can be used to represent IDs of a given type?
I had the following idea but unfortunately it isn’t legal on many levels. You can’t have an abstract struct and the implicit/explicit cast operators wouldn’t be inherited.
public abstract struct Id
{
int _value;
public Id(int value)
{
_value = value;
}
// define implicit Id to int conversion operator:
public static implicit operator int(Id id)
{
return _value;
}
// define explicit int to Id conversion operator:
public static explicit operator Id(int value)
{
return new Id(value);
}
public bool Equals(object obj)
{
if(GetType() == obj.GetType())
{
Id other = (Id)obj;
return other._value == _value;
}
return false;
}
public int GetHashCode()
{
return _value.GetHashCode();
}
}
struct PersonId : Id { public PersonId(int value) : base(value) {} }
struct ProductId : Id { public ProductId(int value) : base(value) {} }
Are there any valid ways to perform something similar? How else can we prove that integer IDs type aren’t being confused across a large application?
Now you can use types
Id<Person>andId<Product>. ThePersonandProducttypes can be either structs or classes. You can even use the actual types that are identified by the id and in that case you do not need any dummy types.The explicit operator overloads allow safe and easy casting between id types and underlying id values. When working with legacy interfaces you may want to change the casting to integer to be implicit, or even better, to overload the legacy interfaces with properly typed versions. Extension methods can be used when the legacy interface is from a third party and cannot be changed or overloaded directly.
Edit: Added
IIdinterface as suggested by smartcaveman.Edit: Changed both operators to be explicit after thinking about Alejandro’s suggestion and added a section how to deal with legacy interfaces.