-----Need ----
Why do we need our public API(s) to be fluent at all ?
In developing a piece of software, we always strive to separate the common from the variable.
For e.g., externalizing configuration is always a good idea instead of re-compiling code for
every small configuration change. We can express the externalized configuration in a language
easy for non-developers to reason about ; it can be in XML form or any custom domain specific
language. If we do choose to write the DSL in our main programming language, we need to do
away with API wiring and ceremony. The DSL must flow as prose so that it is easy to reason
about. Fluent API is an attempt in that direction.
----- Design considerations ----
-
Shared functionality (data/behaviour) is declared only once in the object hierarchy -
in parent and specific responsibility delegated to derived classes. -
Not all attributes are equal ; some might be mandatory and rest optional. This introduces
the need of validating object state before persistence/business logic is applied. -
Any self-documenting code (like the fluent approach) must keep the following in mind :
a. How to ensure the method call order so that the object state is correctly set.
b. How to allow terminal methods to be called only after mandatory state has been set.
c. How to conditionally execute a fluent method.
---- Techniques to create fluent interfaces ----
- Method chaining
- Factory classes
- Named parameters
In languages that support them (including Smalltalk, and C#) named parameters provide a way
to include additional "syntax" in a method call, improving readability.
myDocument.Save(toFile:"SampleFile.txt", withPermissions:FilePermissions.ReadOnly);
---- Project model ----
All the semantic models(objects populated by a DSL) used in this project are in-memory object
models.
---- Conclusion(s) drawn ----
-
Fluent interfaces are more about context, and are so much more than just ways to configure
objects. What that means is, when we typically do many actions in a sequence with the same
thing, we can chain the actions without having to declare that context over and over. -
For a fluent interface to be effective, we need situations where you actually have all
the information upfront (e.g. configuration mostly) so that we can chain the methods in a
fluid way
---- Good examples of fluent api design ----
- JQuery
- Linq
- EasyMock
- Jooq
---- Developers with opinion ----
Paul M. Jones
Eric Evans
Martin Fowler
---- Additional literature ----
https://www.hanselman.com/blog/TheWeeklySourceCode14FluentInterfaceEdition.aspx
https://dzone.com/articles/factories-builders-and-fluent-
https://en.wikipedia.org/wiki/Fluent_interface
https://en.wikipedia.org/wiki/Bounded_quantification#F-bounded_quantification
https://blog.allinsight.de/fluent-interface-pattern/
http://www.erikschierboom.com/2014/10/08/fluent-interfaces/
https://blog.jooq.org/2012/01/05/the-java-fluent-api-designer-crash-course/
http://www.unquietcode.com/blog/2011/programming/using-generics-to-build-fluent-apis-in-java/