Design By Contract or DBC defines that methods should have defined input and output verifications. Therefore, you can be sure you are always working with a usable set of data in all methods and everything is behaving as expected. If not, exceptions or errors should be returned and handled from the methods. To read more on DBC read the wikipedia page here.
In our example here, we are working with input parameters that may possibly be null. As a result a NullReferenceException would be thrown from this method because we never verify that we have an instance. During the end of the method, we don’t ensure that we are returning a valid decimal to the consumer of this method and may introduce methods elsewhere.
1: public class CashRegister
2: {
3: public decimal TotalOrder(IEnumerable<Product> products, Customer customer)
4: {
5: decimal orderTotal = products.Sum(product => product.Price);
6:
7: customer.Balance += orderTotal;
8:
9: return orderTotal;
10: }
11: }
The changes we can make here to introduce DBC checks is pretty easy. First we will assert that we don’t have a null customer, check that we have at least one product to total. Before we return the order total we will ensure that we have a valid amount for the order total. If any of these checks fail in this example we should throw targeted exceptions that detail exactly what happened and fail gracefully rather than throw an obscure NullReferenceException.
It seems as if there is some DBC framework methods and exceptions in the Microsoft.Contracts namespace that was introduced with .net framework 3.5. I personally haven’t played with these yet, but they may be worth looking at. This is the only thing I could find on msdn about the namespace.
1: public class CashRegister
2: {
3: public decimal TotalOrder(IEnumerable<Product> products, Customer customer)
4: {
5: if (customer == null)
6: throw new ArgumentNullException("customer", "Customer cannot be null");
7: if (products.Count() == 0)
8: throw new ArgumentException("Must have at least one product to total", "products");
9:
10: decimal orderTotal = products.Sum(product => product.Price);
11:
12: customer.Balance += orderTotal;
13:
14: if (orderTotal == 0)
15: throw new ArgumentOutOfRangeException("orderTotal", "Order Total should not be zero");
16:
17: return orderTotal;
18: }
19: }
It does add more code to the method for validation checks and you can go overboard with DBC, but I think in most scenarios it is a worthwhile endeavor to catch sticky situations. It really stinks to chase after a NullReferenceException without detailed information.
This is part of the 31 Days of Refactoring series. For a full list of Refactorings please see the original introductory post.
Posted
Aug 25 2009, 08:02 AM
by
schambers