Designing an API to work with the IDE
In a recent blog post, Lou Franco describes how Microsoft's LINQ syntax is designed so that the Visual Studio IDE can easily autocomplete identifiers as the programmer writes queries. He asks:
The idea of language features being designed for the IDE leads to the question of whether API's should be designed for the IDE as well.
I think they should. Steve and I designed the jMock API to work well with IDEs. The chained method "Embedded DSL" API of jMock 1 was designed so that the IDE's autocompletion would act as a "wizard", guiding the programmer through the process of creating complex expectations. However, using strings for method names did not work so well with refactoring IDEs.
The new jMock 2 API works well with refactoring IDEs, but does not have as many chained methods and so is not quite as good at using autocompletion as an expectation wizard. It can also confuse some automatic code formatting tools. However, you can autocomplete on the names of mocked methods, which was not possible in jMock 1.
Like any design, an API must trade different constraints off against one another. Overall, I think, the jMock 2 API is an improvement and works better with features that are common in Java IDEs, if not yet in Microsoft's tools.