Probably the most important thing to notice about this style is that the intent is to do something along the lines of an internal DomainSpecificLanguage. Indeed this is why we chose the term 'fluent' to describe it, in many ways the two terms are synonyms. The API is primarily designed to be readable and to flow. The price of this fluency is more effort, both in thinking and in the API construction itself. The simple API of constructor, setter, and addition methods is much easier to write. Coming up with a nice fluent API requires a good bit of thought. Indeed one of the problems of this little example is that I just knocked it up in a Calgary coffee shop over breakfast. Good fluent APIs take a while to build. If you want a much more thought out example of a fluent API take a look at JMock. JMock, like any mocking library, needs to create complex specifications of behavior. There have been many mocking libraries built over the last few years, JMock's contains a very nice fluent API
Z. Toups, I. Dolgov, und E. Bonsignore. Proceedings of the First ACM SIGCHI Annual Symposium on Computer-human Interaction in Play, Seite 445--446. New York, NY, USA, ACM, (2014)
R. Schaefer, S. Bleul, und W. Mueller. Engineering Human Computer Interaction and Interactive Systems, Volume 3425 von Lecture Notes in Computer Science, Springer Berlin Heidelberg, (2005)
J. Chang, und M. Bourguet. Proceedings of the 22Nd British HCI Group Annual Conference on People and Computers: Culture, Creativity, Interaction - Volume 2, Seite 123--126. Swinton, UK, UK, British Computer Society, (2008)
F. Paternò, C. Santoro, und L. Spano. Model-Driven Development of Advanced User Interfaces, Volume 340 von Studies in Computational Intelligence, Springer Berlin Heidelberg, (2011)