Join Robby Millsap for an in-depth discussion in this video Defining a fluent interface, part of Fluent API Development in C#.
- [Instructor] "He, Gatsby, had waited five years "and bought a mansion where he dispensed "starlight to casual moths." This is one of my favorite lines from one of my favorite books. Picture in your mind a dark night out by the sea. You hear the soft waves of the ocean in the background. Suddenly, a bright light like a star appears in the middle of that darkness. Now picture an eclipse of moths fluttering their wings and congregating around that light. This is the metaphor that F. Scott Fitzgerald uses to describe Gatsby's outrageous parties.
And this is the power of prose. Great prose does more than explain. It creates pictures in your mind, conveying the author's meaning through thought transmission. The definition of fluent is being able to express oneself easily and articulately. Now, paint a picture in your mind from these words. Gatsby saved up a lot of money and threw a bunch of parties that were really expensive. A lot of people came. What do you see in your mind? Do you see the image of the party-goers dancing around the light? This, to me, reads like a checklist.
Gatsby had money, threw expensive parties, and people came. That's great, but it's not very compelling and I'm not likely to ever want to read this story. Code, too, has prose. After all, code is just a set of machine instructions meant to be read and understood by humans. Computers don't care if our code is readable, if our comments are provocative, or if we've used polymorphism in a clever fashion. So, if code is intended to be read by humans, doesn't it follow that the more engaging our prose, the more users of our API will want to understand its purpose? Won't they be more likely to benefit from our APIs? Fluent interfaces are useful when creating domain-specific languages.
That is when our code ends up having a style of its own that is specific to our application. It helps us to find the expectations for input, output, and it can assist in providing the order of steps needed to complete a task. A key point I want to convey up front. Fluent APIs are not a strategy for writing the least amount of code to get the job done. There will be times in this course where you might want to scratch your head and wonder, is all this effort really worth it? That's one reason I've decided to include some mature fluent libraries. By seeing what others have done, it is my hope that you will get an appreciation for the end goal and understand why this is all useful.
Fluent is not a fix for writing buggy or spaghetti code. It's not an alternative to test-driven development. Fluent code is very testable. Fluent isn't what people refer to when they say you should write clean code. Fluent is neither clean nor dirty. Fluent is a technique for creating code that flows like prose. How you write the code behind the interfaces determines whether or not you're following clean code practices. Fluent interfaces are typically domain-specific and not for general use outside of their intended purpose. For example, the language of fluent assertions has language that supports how we create assertions in our unit tests.
The term fluent, as it applies to code, was first coined by Martin Fowler and Eric Evans as a way to describe a set of interfaces that allow statements to be wired together, creating a natural language for users of your code. The example Fowler presented on his blog was looking at a mechanism for returning a date span. Here, we have two examples of a date. Both return a date span. The first uses a constructor that requires the user know that a date time span takes two date parameters, a starting date and an ending date, and in that order.
The second date example, labeled fluent here, takes an existing date object and has an easy-to-understand fluent interface that provides days until that returns the time span when provided a second date argument. Fluent interfaces have come a long way since this concept was proposed, but the idea of clearly communicating the underlying functionality of your code has remained the same.
- Why fluent?
- Creating paths
- Fluent techniques
- Examples of fluent APIs
- Refactoring to fluent