The Power of Classes

F# classes give you the full power of object oriented programming. When you need to go beyond record types, for example, when the external and internal representations of data need to differ, or when you need to hold or even mutate state over time, classes are often the answer. They are also a great solution when you need to interact closely with an OO codebase, for instance, by participating in a class hierarchy. F# classes can inherit from C# classes and can implement C# interfaces, and vice versa.

By the way, I’m avoiding using the phrase class types (although that is what we are talking about), because there also exists a rather different concept, confusingly called type classes. Type classes aren’t supported in F# at the time of writing, although there is work going on in that area so perhaps someday they will be. I’m not going to talk about them at all in this book, and I’ll stick to the term class for object oriented F# types and their C# equivalents.

Asymmetric Representation

One place where you may want to use a class is where the internal and external data representations need to be asymmetric. In other words, the set of values you see when you use an instance isn’t the same set you provided when you created the instance.

ConsolePrompt is a great example of asymmetry: when you create an instance, you provide a prompt message, but there is no property that lets you get that message back. (Why would there be? It's sufficient for that message to be printed out when prompting for input.) Conversely, the class’s one member, GetValue(), returns something that is independent of anything that was provided on construction, because what it returns was typed in by the user.

Constructor Bodies

There are two kinds of operations you can conduct in a constructor body. One is imperative operations: actions that do something but which don’t return anything. Imperative actions commonly performed here include validation of the constructor arguments, and possibly logging. In this case we validate the prompt message to make sure it isn’t null or blank. Imperative actions in F# class constructor bodies must be contained within a code block beginning with the keyword do .

The other kind of thing we can do in the constructor is to bind values using the let keyword. In Listing 8-2 we bind a new value for message, containing the original message value but with any leading or trailing spaces trimmed. This is an example of shadowing, not mutation. The original value for message isn’t overwritten, it’s just hidden because there is a new thing in the same scope with the same name. In this case, because the cleaned-up message is the definitive version, and we don’t want any later code to access the original input, it’s reasonable to use the same name. Again, as with constructor arguments, values bound with let in the constructor body are available throughout the body of the class, including in all its methods. You don’t use a self-identifier like this to access them, as they aren’t properties.

Values as Members

Here we publish the cleaned-up version of message as a property called Message. Callers can access the value using dot notation. No brackets are needed after the definition or call, because it’s a read-only property that simply gets the value of message, which itself never changes.

Getters and Setters

Using a so-called auto-implemented property is a reasonable thing to do here: BeepOnError is not an important enough thing to have as a constructor parameter, and a default value is fine; but one would also like to have the flexibility to change it. And as a Boolean it hardly needs validation!

Additional Constructors

In Listing 8-5 we’ve added a beepOnError parameter to the primary constructor, and accessed its value in GetValue() when deciding whether to beep. Then we’ve added an additional constructor after the body of the primary constructor (i.e., after the validation and trimming of message). Secondary constructors are always declared using the new keyword (you don’t use the name of the class), and must always call the primary constructor. In this case we call the primary constructor with whatever message value was passed in, and a hardwired default value of true for beepOnError.

Additional constructors are useful, but having more than a very small number of them may be a code smell. If you need so many permutations of construction values, does your class really have a “single responsibility,” as it should?

Explicit Getters and Setters

Internal Mutable State

There’s nothing inherently evil about a mutable state, especially, as here, where nothing else can directly see or change it. That said, you do have to be a bit canny about thread safety. It’s hardly likely in the case of ConsolePrompt, but what would happen if two threads were to call GetValue() and both happened to check attempts < maxAttempts simultaneously? Both might pass the check before either of them incremented attempts. Both threads would then perform the recursive GetValue() call, meaning that the total attempts could exceed the specified limit. Whenever there is mutation, you should always consider thread safety, even if it’s only to document “this method is not thread safe.”

Generic Classes

Then we need to think about how to convert from what the user enters into the type we want (string, integer, floating point, or whatever). We also need to take into account that the user might not type in what we expect: if they type “abc” or just press Enter, we won’t be able to convert that into an integer, so we must build in the possibility of failure.

(I’ve kept the maxAttempts parameter from the previous section as it’s relevant to how we’ll need to use the converter.)

It’s interesting to note that we don’t need to change the signature of GetValue to make it return 'T rather than a string. The fact that it uses tryConvert to generate a return value, and that tryConvert returns 'T, is enough for type inference to do its job.

This works as well as Listing 8-9, but I personally think it is slightly less readable. On the other hand, if one needed to perform additional operations on the tryConvert result, then there would be more of a case for using Option.defaultValue, as the functions in the Option module pipe together nicely.

Named Parameters and Object Initializer Syntax

In my opinion, named argument syntax isn’t used enough in F# code. Object initialization syntax is more well-used, particularly when interacting with C#-based APIs, which tend to make extensive use of mutable properties. In fact, I would say: if you find yourself creating instances and immediately setting their properties, always change this to object initializer style.

Make sure you give some thought to which style you adopt. Naming at the call site can be very helpful to the reader, especially when you are calling APIs that require you to set lots of constructor arguments and mutable properties.

Indexed Properties

We’ve already learned how to provide simple properties in a class by providing default or explicit getters and setters. That’s fine if the properties are single values, but what if you want a class to provide a collection property: one that you can access with the syntax property.[index]? For example, let’s implement a ring buffer: a structure that contains a collection of length n. When we access elements beyond the last, we circle back to element number (index modulus length). For instance, in Figure 8-1, element [8] is actually the same item as element [0].

The important part here is the member called Item. When a property has the name Item and an index argument (here we used i), it describes a read-only, indexed property that can be accessed by the caller using array-like syntax. Notice that I used the name _items for the array backing store. I could instead have shadowed the original items sequence by reusing the name items for the backing store array. I used a private backing store to avoid potentially slow indexed access into the provided sequence.

The one subtlety here is that the dimension index parameters (i and j in this case) must be tupled together. But the value parameter in the set declaration is curried – that is, it’s outside the brackets that surround i and j.

Interfaces

Interfaces are a key concept of the Object Oriented world. An interface lets you define a set of members in terms of their names and type signatures, but without any actual behavior. Classes may then implement the interface, in other words, provide member implementations that have the same names and type signatures as the members defined in the interface.

Listing 8-15 starts with a couple of type aliases, which give new names for the string and int types. I’m not a huge fan of littering code with type aliases, but when defining interfaces, they make a lot of sense. They help motivational transparency by incorporating meaningful names for both parameters and results in the type signature. Next we have a Discriminated Union called Status, which embodies the states that the media player can be in. Finally, there is the actual interface definition. It starts with type <Name>, just like a class definition, but since there can be no constructor, the name isn’t followed by brackets or constructor parameters.

The definition of the interface consists of a series of abstract member definitions, each of which must have a name, such as Open, and a type signature, such as MediaId -> unit. Use the keyword unit if you need to express the fact that the member doesn’t require any “real” parameters, or that it doesn’t return anything “real.”

The beauty of this approach is that you can start to think about the design of your classes (the ones that will implement this interface) without getting distracted by implementation details. For example, the fact that Open has a signature of MediaId -> unit tells you that implementations of Open aren’t going to return any feedback to the caller about whether they successfully opened the requested media item. This further implies that any failures are either swallowed and not reported back, or are signaled in the form of exceptions. That might or might not be the best design: the point is that you can think about it here, before committing to a lot of coding in either the implementation of classes or their consuming code. If you have become accustomed to designing systems based on function signatures, you could think of an interface as a sort of big, multi-headed function signature.

Implement the interface by adding interface <Interface Name> with, followed by implementations for each member in the interface. Each member declaration replaces the abstract member from the interface with a concrete member containing real code. The implementation needs to have the same function signature as the interface member it is implementing.

In Listing 8-16 I’ve called the implementation DummyPlayer because this class doesn’t really do very much – it certainly doesn’t actually play media! But you can see how a real implementation would fit into the same interface/implementation pattern.

To help me remember which operator to use, I visualize the upcast operator :> as a sort of sarcastic emoticon, saying “Haha, you forgot to cast to the interface… again!”

The class in Listing 8-18 implements two interfaces: IMediaPlayer and IDisposable , and it also creates a memory stream in the class constructor, just as an example of a resource that the class might want to dispose promptly when it itself is disposed. It also has a member of its own, called UniqueId. In the demo() function, we create a player, open a media item, then explicitly dispose the player. (By the way it would be better generally to create the player with the use keyword or the using function, meaning that the player instance would be disposed on going out of context. I’ve coded in this way so you can see the casting in action.)

Notice how, to call the Open() method, we cast to IMediaPlayer; to call the Dispose method we cast to IDisposable; and to use the UniqueId property we don’t cast at all, because this is a member of the class itself. You might wonder why I didn’t have to cast the stream instance to IDisposable when calling its Dispose() method. The answer is that the C# code for MemoryStream didn’t implement the IDisposable interface explicitly. F# always implements interfaces explicitly; in C# you have the choice.

Object Expressions

You can use an object expression to create a “something,” which inherits from a class or implements one or more interfaces, but which is not a new named type. It’s a great way of creating ad hoc objects for specific tasks, without actual, named types proliferating in your codebase.

In Listing 8-19 we make a new implementation of IMediaPlayer that requires a logger as a constructor argument. The logger needs to be of type ILogger, which I’ve also declared here but could just as easily be defined externally. The LoggingPlayer implementation calls the logger’s Info and Error methods at various points.

The object expression part comes in the demo() function, where we create a value called logger that implements ILogger but is not a new, named type. The curly brackets {} are important here: they are part of the object expression. When various members of the LoggingPlayer instance are called, these call the methods we defined in the logger binding.

I personally don’t use object expressions very often, but they can certainly be useful. The times I have used them have been in writing tests in F# for highly coupled C# codebases. There they really have been a boon.

Abstract Classes

Confused yet? Let’s look at some examples.

Class Equality and Comparison

Although many F# developers don’t use inheritance or interfaces a great deal, there are a few standard interfaces that we often have to support. One is IDisposable , which we dealt with briefly above. The others are IEquatable and IComparable , which are used to determine if two instances are equal in some meaningful sense, and whether one is larger or smaller than another.

Recommendations

Summary

The chapter has two messages. The explicit message is “Here’s how to do Object Orientation in F#. Here’s how to write classes, use interfaces, override methods and so forth… .” The implicit message is “Object Orientation can be a slippery slope.” Compare, for example, what we ended up with in Listing 8-29 with what would have been achieved, almost for free, using an F# record. (Accepting the dangers and limitations of comparing floating-point values, which apply to both the class and the record version.) Also, it’s interesting to note that this chapter is the longest in the book, and was by far the hardest to write. It’s hard to be concise when writing classes, or writing about classes!

So that you can make informed design decisions, make sure you are familiar with the basics of F# classes, constructors, overrides, interfaces, and abstract classes. Don’t forget how useful object expressions can be for making ad hoc extensions to a class without a proliferation of types. Above all, be extremely cautious about implementing deep hierarchies of classes. I’ve rarely seen this turn out well in F# codebases.

In the next chapter we’ll return to F# fundamentals and look at how to get the best out of functions.

Exercises

Exercise Solutions