Just because your language can do it, it doesn't mean that you should.
You can't "grow" a fluent API; you need to understand how developers will need (and expect) to use your API. Here's a case study of what the design process for a fluent API looks like.
Peter continues to look at the value of imposing naming conventions on developers; but this time, he looks at the benefits related to understanding the business problem, as well as why flexibility is crucial.
Here's how to implement a fluent API for a single class that supports the goals of fluent interfaces.
Just because you've created an application, it may not need a user manual, guide or help system. And, even when your application does need that kind of support, you should -- at all costs -- avoid writing it.
Fluent methods are a hot design idea and they can improve the readability of your code. However, they only make sense in specific scenarios. Here are some criteria to help you decide if you should be creating a fluent interface, and some design guidelines for when you do.
Peter returns to the topic of managing multiple users accessing the same row in a table using Entity Framework, but this time using code-first development. There are some unexpected issues to deal with.
Naming conventions are obviously a good thing, right? Not necessarily -- and only if you understand the problem they solve.
After having a UI design invalidated during usability testing, Peter has to find a way to figure out what the user wants the application to do.
There's no doubt that the ASP.NET Web API is a wonderful thing. But developing services that support content negotiation in a testable way requires a little setup.
Peter looks for help in building an extension method that will let him compare two objects in a Visual Studio Test. In return, he introduces the CollectionAssert class.
Claims-based security lets you manage your site's authorization process using any criteria that makes sense to you. And the Microsoft .NET Framework 4.5 provides some performance support for you once you start using claims-based security.
Here's an example of how user stories, personas, usability testing and the practicalities of navigating with a mouse define a UI. Peter Vogel also discusses how he feels about error messages.
Peter looks at how rewriting some complex code -- purely to make it easier to read -- eliminates the need for writing comments. He even adds a comment to some code.
Microsoft .NET Framework 4.5 support for claims-based security can make your existing authorization system more powerful and flexible, even if you never intend to start working with third-party security providers. Plus, it's backward-compatible with virtually all of the authorization code you're already using.