This article is cross-posted from my personal blog.
In this new blog series of short posts I will “uncover” little know classes/methods - “gems” - in the DotNetNuke Framework (and any of the 3rd party libraries that we use, such as Telerik or the .NET Framework itself).
In this first post, we look at two new helper modules in the DotNetNuke.Common namespace. A Visual Basic Module is equivalent to a C# static class (ie a class where all the members are static).
What do these helper classes do?
In short they provide wrappers around typical defensive coding practices, that make the code more concise and more importantly more readable.
Lets look at a theoretical example.
Figure 1: An example of a method with typical defensive coding
|
1: public virtual IWidget Createwidget(string widgetType)
2: {
3: //Make sure that the string passed in is not null
4: if (String.IsNullOrEmpty(widgetType))
5: {
6: throw new ArgumentException("Argument is null", widgetType);
7: }
8:
9: IWidget widget = WidgetFactory.CreateWidget(widgetType);
10:
11: //Make sure that the Widget returned is not null
12: if (widget == null)
13: {
14: throw new InvalidOperationException("Widget Factory returned a null widget");
15: }
16:
17: return widget;
18: }
|
In this example we have a method that creates a widget when given a widget type.
The method first checks if the widget Type passed in is not null or empty, and throws if it is. In line 9 the widget is created by calling a factory method which (presumably) creates the appropriate type of widget depending on the string passed.
Finally before returning the widget, a check is made to ensure that the widget is not null.
This method is quite readable but it is 18 lines long. The guts of the method is in one line (Line 9) – the rest is defensive coding. Important defensive coding – but typical boiler-plate code that we should find ourselves writing repeatedly.
Lets rewrite this method using the new classes.
Figure 2: The method rewritten using Requires and Guard helper classes
|
1: public virtual IWidget Createwidget(string widgetType)
2: {
3: Requires.NotNullOrEmpty("widgetType", widgetType);
4:
5: IWidget widget = WidgetFactory.CreateWidget(widgetType);
6:
7: Guard.Against(widget == null, "Widget Factory returned a null widget");
8:
9: return widget;
10: }
|
While the Requires and Guard classes both provide helper methods that, in theory, accomplish similar tasks, we have two classes as the code is more readable.
The Requires class provides methods that enforce certain conditions that are “required” for the method to execute successfully. So the first line “requires” that the parameter passed is not null or empty. The Guard class provides a single method Against which takes a boolean as a parameter, which we can use to “guard against” (defend) a particular exception-case condition.
We could have written line 3 as:
Guard.Against(String.IsNullOrEmpty(widgetType), "widgetType was a null (or empty) string");
or line 7 as:
Requires.NotNull("widget", widget);
but the code would be less readable.
By providing two approaches to writing defensive coding we can make the code much more readable in context, and therefore easier to maintain.
Over time we will enhance these classes with additional methods which encapsulate defensive coding practices into a more readable fluent format.