I often see class
es like
public class Person
{
string FirstName { get; set; }
string MiddleName { get; set; }
string LastName { get; set; }
int Age { get; set; }
}
where one of the properties, say MiddleName
in this example (because some people aren't given a middle name at birth), is allowed to be null
. In my opinion this is wrong because any consumers of the class have to know that the property "might" be null and perform checks like
public void PrintName(Person p)
{
Console.WriteLine(p.FirstName);
if (p.LastName != null)
{
Console.WriteLine(p.MiddleName);
}
Console.WriteLine(p.LastName);
}
How I handle this is by using composition like
public interface IPerson
{
string FirstName { get; }
string LastName { get; }
int Age { get; }
}
public interface IMiddleNamed
{
string MiddleName { get; }
}
and
public void PrintName(IPerson p)
{
Console.WriteLine(p.FirstName);
if (p is IMiddleNamed)
{
Console.WriteLine((p as IMiddleNamed).MiddleName);
}
Console.WriteLine(p.LastName);
}
That is the case even if my models represent data contracts (e.g. "value bags" that are serialized/deserialized through inter-service communication).
In the same way I avoid classes that has null
-able value types like
public class Something
{
public int SomeInt { get; set; }
public double? SomeDouble { get; }
}
for the same reason.
However I'm wondering if this is like "OOP overengineering" as it clearly adds a lot of development time.
Aucun commentaire:
Enregistrer un commentaire