The Special Case Pattern
You have a GetCustomerById method in a factory object inside a repository that, when passed a CustomerId, returns a Customer object. Except, of course, sometimes there isn't a matching Customer object to return. What's the best way to handle this?
You have three options:
- Raise an exception.
- Return Nothing/null
- Return a "special object"
Raising an exception has performance implications because everything stops for tea when .NET processes an exception. Really, you should only raise an exception if you intend to stop processing … and that's not a decision that should be made by some method in some middle-tier object. Stopping the application is a decision that should be made by the application itself.
The second option isn't a bad one … except that quite a lot of code doesn't deal well with null references. By returning null/Nothing you're forcing the developer calling your method to wrap it in a Try…Catch block (there's those exceptions again) or test for null. And a null reference doesn't tell the developer much about what went wrong.
Your third option is really your best choice and it even has a name: The Special Case pattern. The only wrinkle is that your special object has to be compatible with the datatype that your method is returning (Customer, in this case). Your special object will, therefore, need to be some class that shares an interface with the objects that your method normally returns.
If, for example, your method returns a Customer object then your special object will need to be something that inherits from Customer -- a CustomerNotFound class, for example. The CustomerNotFound object should have all of its properties set to their default values.
Now code that calls your method can use the datatype of the special object:
Dim cust As Customer
cust = CustomerFactory.GetCustomerById("A123")
If TypeOf cust Is CustomerNotFound Then
to see what kind of error occurred.
Posted by Peter Vogel on 03/04/2016 at 2:53 PM