by Zoran Horvat
Aug 25, 2015
Options are used in functional languages to indicate that an object might not be present. In classical programming, null references are often used for the same purpose. But null reference comes along with one significant drawback compared to Options: It exists. Null reference is still a reference. We must deal with it - typically through an if-then-else constructs that test whether the reference is null. When there is no object to point to, we prefer not to have the reference in the first place. Why having a reference if there is nothing to refer to? That is where Options come into play.
Let's try to solve a simple task in F#. We want to define a function which receives name of a product and returns price of the product. Price is calculated as Pi dollars for every letter in the product name. The problem is that our shop doesn't hold items with more than six letters in their name. Here is the pseudo-code which does precisely what was asked:
function getPrice (itemName) begin if length(itemName) > 6 then return no-price else return length(itemName) * 3.14 end
The problem in this example, as you may guess, is the positive branch of the if-then-else statement, which covers the case when item does not exist in the shop. In this pseudo-code we have returned something called no-price. But in actual programming languages that construct, whatever it is, must be replaced with something concrete.
One way to deal with no-price case in the previous example is to make the price nullable. Price is a decimal number and .NET languages offer System.Nullable<T> type that can convert any value type to its counterpart that supports null.
One option to return a missing price for an item is the to actually return null value:
let getPrice (itemName: string) = if (itemName.Length > 6) then System.Nullable<float>() else System.Nullable<float>((float)itemName.Length * 3.14)
Although this piece of F# code will work fine, it misses the point altogether. It falls into the trap of having a reference but not having an object to refer to.
Functional languages offer much more effective solution to this problem - Option data type. In some languages it is called Maybe, or Optional, but the idea behind is the same in all cases. Option is a value which either contains another value or contains no value at all.
Fundamental difference between Option and null reference is that null reference is the same whether it is attached to an object or not attached to anything. In case of the Option, you can imagine that there is no reference when there is no object.
Below is the implementation of the getPrice function, this time taking advantage of the Option type and usual functional coding practices:
let getPrice (itemName: string) = match itemName.Length with | length when length <= 6 -> Some((float)length * 3.14) | _ -> None;;
This implementation looks almost exactly like the pseudo-code from which we started. Option type lets us return None or Some. In case of Some, we have to specify what "some" means. In this function, that is precisely 3.14 dollars per letter of the product name.
The last implementation of the getPrice function returns float option. That is the floating point number which either has some value or is missing altogether. Now that we have a proper implementation, we can use it in another function.
Below is the function which matches the float option returned from the getPrice function to format a user-friendly message about the product:
let report (itemName: string) = match getPrice itemName with | Some(price) -> sprintf "You can have %s for $%f" itemName price | None -> sprintf "We don't sell %s" itemName
Since getPrice method returns an option, we can match its result against two options - Some and None.
If Some is the case, then it comes along with a contained value. In this case, function maps to a string saying "you can have the item for this much dollars".
The other case, None, maps to a string which simply says "we don't sell this item".
.NET Framework doesn't ship with Option type. But it is quite easy to implement it. In fact, we can use a collection instead of Option - it could carry a single object or no object. Those are the two cases covered by Option anyway.
You can find custom implementation for the Option<T> type in C# in article How to Reduce Cyclomatic Complexity: Option<T> Functional Type.
Using Options when there is a possibility that the underlying object might be missing is an effective solution. We can rely on other related ideas, such as using LINQ to query Options and map them into subsequent objects. That approach leads to writing code which is easier to understand and easier to manage, compared to numerous if-then-else statements testing references against null.
If you wish to learn more, please watch my latest video courses
This course begins with examination of a realistic application, which is poorly factored and doesn't incorporate design patterns. It is nearly impossible to maintain and develop this application further, due to its poor structure and design.
As demonstration after demonstration will unfold, we will refactor this entire application, fitting many design patterns into place almost without effort. By the end of the course, you will know how code refactoring and design patterns can operate together, and help each other create great design.
In four and a half hours of this course, you will learn how to control design of classes, design of complex algorithms, and how to recognize and implement data structures.
After completing this course, you will know how to develop a large and complex domain model, which you will be able to maintain and extend further. And, not to forget, the model you develop in this way will be correct and free of bugs.
Zoran Horvat is the Principal Consultant at Coding Helmet, speaker and author of 100+ articles, and independent trainer on .NET technology stack. He can often be found speaking at conferences and user groups, promoting object-oriented development style and clean coding practices and techniques that improve longevity of complex business applications.