I like some fluent interfaces. Not that I’d like everything API to be this way, but in some situations, it certainly helps due to its expressiveness. The only problem is that, if not created properly, it is difficult to choose the next method in the chain. For that purpose a different type of fluent interface, the so called progressive interfaces, was ideated. The difference is that with the later, the user of the interface will only have available those methods that can be chained for the given link. In other words, progressive interfaces are fluent interfaces that are easy to explore.

A Real Problem

The problem space in hand is very simple: how to write the urls of a web application, being them virtual that have very little resemblance with any physical paths and somewhat different to the urls of a CMS.

A Boring Solution

The first approach (what we currently have) is a service class with a bunch on methods, one per “area” (related group of pages) that receives a textual parameter that represents the page in the are. It is simple but I do not like its “stringyness” and, although effective enough (long urls have more parameters than simple ones), I had time to improve it a little bit, so I did.

But before, let’s check how its usage would look like:

Looking Beyond

Good enough only. It fails to enforce some building logic in the case of complex arguments, yielding slightly surprising results, and you all should know by now that coding and surprises make up a bad couple in my eyes.
It can be improved. The requirements for that improvement are really simple:

1. enforce the building rules with the API so that
2. knowing when one has finished building the url must be easy

Building a progressive interface takes care of #1. And the inner closure pattern takes care of #2.

I can’t wait for the next post in the series, which will put some meat to the “progressive” part of the title and bring lots of code.