.Net Head

When Microsoft added support for nullable types, why didn’t they add reasonable ToString() implementations as well? The idea that I cannot call someDate.ToString(“mm/dd/yyyy”) or someDecimal.ToString(“C”) and the like on Nullable<DateTime> and Nullable<decimal> respectively drives my bonkers. So I have written the following extension methods to restore my sanity.

using System;
 
public static class NullableExtensionMethods
{
    ///
    /// If null return "NULL" otherwise returns value.ToString();
    ///
    public static string ToStringOrNullText(this T? value) where T : struct
    {
        return value.HasValue ? value.Value.ToString() : "NULL";
    }
 
    ///
    /// If null return an empty string otherwise returns the value formated according to the format string;
    ///
    public static string ToString(this DateTime? value, string format)
    {
        return value.HasValue ? value.Value.ToString(format) : string.Empty;
    }
 
    ///
    /// If null return an empty string otherwise returns the value formated according to the format string;
    ///
    public static string ToString(this decimal? value, string format)
    {
        return value.HasValue ? value.Value.ToString(format) : string.Empty;
    }
}

Obviously, this approach can be extended to other types as well.

This page does not contain anything you can’t find better explained elsewhere.  However, these methods show up in a lot of my code so I figure I had better post them.

Methods to get the Property Name referenced in a Lambda Expression

The below methods act on lambda expressions of the form “x => x.SomeProperty” and return the name of the referenced property (“SomeProperty” in this case).

The first method is for the typical case where one doesn’t know at compile time what the return type of the property is.  Therefore it is implemented using a return type of object.  The second method is for the occasional situation where the return type is known and one wants to use a strongly typed lambda.

For a fuller explanation of these methods see this excellent blog post from which I shamelessly lifted it.

For an example of how to use these methods, see this post.

using System;
using System.Linq.Expressions;
using System.Reflection;
 
static class ExpressionExtensionMethods
{
    public static string GetReferencedPropertyName
        (this Expression propertyReference)
    {
        return GetPropertyNameReferencedByExpression(propertyReference);
    }
 
    public static string GetReferencedPropertyName
        (this Expression propertyReference)
    {
        return GetPropertyNameReferencedByExpression(propertyReference);
    }
 
    private static string GetPropertyNameReferencedByExpression
        (LambdaExpression propertyReference)
    {
        MemberExpression memberExpression;
        var unary = propertyReference.Body as UnaryExpression;
        if (unary != null)
            //In this case the return type of the property was not object,
            //so .Net wrapped the expression inside of a unary Convert()
            //expression that casts it to type object. In this case, the
            //Operand of the Convert expression has the original expression.
            memberExpression = unary.Operand as MemberExpression;
        else
            //when the property is of type object the body itself is the
            //correct expression
            memberExpression = propertyReference.Body as MemberExpression;
 
        if (memberExpression == null
            || !(memberExpression.Member is PropertyInfo))
            throw new ArgumentException(
                "Expression was not of the form 'x => x.property'.");
 
        return memberExpression.Member.Name;
    }
}

For any of you who know who Uncle Bob is, you probably know he is a “fanatic” about the idea that methods should do one and only one thing.  If you have any doubts about this, check out his recent blog on the matter.  However I put “fanatic” in quotes because I am in complete agreement with him on this (and most other) points.

There are lots of reasons for keeping your functions this tight.  Combined with good method names, it makes for great self-documenting code.  It makes code reuse a lot easier because you never have code that does one thing tangled up with code that does something else.  That in turn makes it easier to keep your code DRY; if code is easily reused, there is rarely any reason to duplicate it.  All of these points, and their relationships, are often discussed.

One relationship I have not seen mention of, though it is implied in the above, is the relationship between Do-One-Thing (DOT) and the Open Closed Principle (OCP).  This relationship has had opportunity recently to re-impress itself upon my mind, so I thought I would take some time to discuss it.

For those not familiar with OCP, the Wikipedia entry gives a concise explanation.  For a more in depth, applied look, see Uncle Bob’s treatment of it.  For the real short summary, here is the definition from the latter.

Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.

Another way to say this which gives the sense in which I wish to discuss it here is this: Given an existing class, if I need to modify the behavior of the class, I should be able to do so solely by means of subclassing it.  I should not need to make any modifications to the class itself.

To clarify, this is important in scenarios where the original class is used by code beyond that which needs the modification.   If all code that uses a class needs the modification (such might be the case with a bug fix) then by all means the original class should be modified.  But if a modification is needed by only some users of the class, then OCP comes into play.  In this case we want to leave the original class unmodified in order to ensure that the other users are not affected by the change.  The code which needs the change, and only that code, uses the new subclass.

In contrasts to OCP, what often happens is this:  I have a new feature to implement that requires a slightly different behavior from the FooBar class.  FooBar is used by other features of the application that rely on the current behavior.  I could just make a copy of FooBar and modify it to fit my needs, but DRY says that is bad, so I correctly decide to subclass FooBar and just override the method that needs to behave differently.  So far so good.

So I pull up the source code for the FooBar class and find the code that I need to override.  It is in the Transmorgify() method.  But now things get messy.  Transmorgify() doesn’t adhere to the Do-One-Thing principle.  It does several things.  But I only need to override one of them.  Now I am in a conundrum.  I have two options.

1. I can override the current Transmorgify() method and copy its current implementation into my override, and modify the part that I need modified.  That violates DRY.
2. I can refactor Transmorgify() by extracting each behavior into its own function as Uncle Bob demonstrated above–then override the new more narrowly focused method. But that means modifying the existing code and possibly breaking something–a potentially costly error.

As can be seen, the failure to adhere to Do-One-Thing resulted in a failure to adhere to the Open Closed Principle.  To put it succinctly, a class cannot be closed to modification if any behavior that might, in the future, need to vary independently of another behavior is implemented in the same method as that behavior.

That is an ideal statement.  Realistically, it may be hard to identify every potential vector for change let alone isolate them.  And even if it can be done, the ROI might not be there.  Uncle Bob himself acknowledges this in his treatment of OCP.  (See page 6 on “Strategic Closure.”)  But this really goes back to the question of how far to take Do-One-Thing.  If you can, “do it till you drop.”  But if time constraints and ROI issues impose, then at least go as far as you can and error on the side of excess.  Why? Because we are human and we tend to error the other way because it is easier and faster.  So trying to error on the side of excess is more likely to get us into an appropriate middle ground.

No matter how hard we try to avoid them, ultimately, we are going to encounter scenarios like the above.  When it happens, the best thing is to have a comprehensive set of tests in place and refactor the original class as needed.