the ideal client code as design

It is still an open question how to approach most programming problems: what to do first? how much design is enough? Some methodologies are trying to answer these questions. TDD comes to mind, or bottom-up programming, or domain-driven design. What I've been trying to discipline myself to do these last few months is to ask myself: what would the perfect interface be?

I don't code, I don't test. I just ponder about the best possible interface for this new feature. What would ideal code using this feature look like? I'm thinking about the method names and what is the least amount of information that I must give in order to implement the desired behavior. For example, I want to create a window with a given title. Then I want to add a button to it that quits the application, but only quits if the current document does not have outstanding changes.

I think the following code would look great:

create_window("title") and add_button do   quit if unchanged end

It doesn't matter what functions or classes already exist or how the hell am I going to get a handle to a thousand objects. I try to build the ideal client code. I am using ruby syntax at the moment but I could also use pseudocode -- it might even be more educational using pseudocode.

As another example, I want to create an email from a string and send it to Bob at 3pm:

at 3.pm do   create_email("body").send_to(:bob) end

The underlying assumption is that if the client code makes sense to the domain expert, the domain code will have to bend over backwards to represent the domain better. For instance we could also fancy sending an email like this:

send_email("body").to(:bob) | 3.pm

The two forms look nice to me but if the application represents a clock triggering actions at specific times, I would choose the first one. If the application feels more like an email client, I might choose the second form. The point is that I am free to think about what makes sense in the domain, free from the current codebase, free from scope rules or whatever stupid design decision I made yesterday.

The way to go from "ideal code" to the actual implementation is usually easy. I like to write the ideal code in a test file, make it compile by whatever means, and increment slowly to hook the code up to the rest of the application. Sometimes a revelation will come and prevent the ideal code from happening and that's fine, although too many of these might be a smell.

This "client code as design" is of course nothing new. It's in the same cluster as DSLs, and UCD.