I see industry backing for Fluent Interfaces. It is in more places than you may know. In my opinion, all people in the software industry will want to know what Fluent Interfaces are, where they are used, and how they fit into the canvas of what they care about.
What are Fluent Interfaces? Fluent Interfaces is an API style that empowers the user of the API to programatically express something in a natural and easy to read way. Martin Fowler describes Fluent Interfaces well. See http://martinfowler.com/bliki/FluentInterface.html
Steve Asher explores Fluent Interfaces in-depth from the user and designer point of view at his Build Without Boundaries blog at http://buildwithoutboundaries.blogspot.com. Search for Fluent API.
Having Martin Fowler support Fluent Interfaces is huge. I also see Fluent Interfaces as the bridge towards Domain Specific Languages (DSL). Are DSLs a possibility in mainstream software development?
Kent wrote in a JavaRanch post that there is a transition from OO languages to DSLs (Domain Specific Languages). What a powerful statement! Is it true? What's the sticking power to Fluid Interfaces and DSLs?
The Object Oriented (OO) approach to programming caught on because it feels natural. We play with objects in life. We speak about them within the context of a domain. The customers speak from within their domain perspective. The easier the trip between the problem domain concepts and reflecting those concepts in code the better.
Who's presenting their API / functionality via a Fluent Interface? Thanks to Steve Asher, I now know JUnit has begun that journey. See http://junit.sourceforge.net/doc/ReleaseNotes4.4.html where the assertThat(...) example is given. JMock uses a fluid interface too. See http://jmock.org/expectations.html If you search for "new Expectations" twice you will see examples of a Fluid Interface in action. It is used also where I work at CARFAX. Again, I refer you to the Build Without Boundaries blog.
Similar to the time when people implemented Object Oriented concepts via languages like C and Ada, we will see people using Fluid Interfaces and other approaches with existing languages. The benefits are likely to outweigh most difficulties and challenges.
The next step for DSLs and Fluid Interfaces will be stronger support and perhaps new languages entirely. Will the fashion of Fluid Interfaces and DSLs hold? Time will tell.
6 comments:
I think that you are definitely on to something by comparing the use of Fluent APIs today to the days of people writing semi-OO C and Ada. I remember doing that, with function pointers in my stucts. It seemed awkward, but it did allow for some OO-like features. Moving to real OO languages felt like a weight off of my shoulders.
If your analogy is accurate, and I hope it is, we should expect new features, languages and tools to support Fluent APIs. How long can we expect it to take though? Even today I feel like mainstream OO languages are not OO enough! Why do we even have primitive types anymore? It is nice in Ruby and Groovy where everything is an object. Autoboxing is nice, but it is just not the same. Likewise, true closures would be a windfall for Fluent APIs in Java. Still, I have to wonder what great innovations we will be denied in the mainstream for the sake of backwards compatibility and convention.
Great comment and points! We will want to keep our eyes open.
*Are DSLs a possibility in mainstream software development?*
I'm going to be a little bit of an instigator, and contend that DSLs have always been possible in mainstream software development to the extent that the option to use Lisp has been present. ;)
I'll just point out quickly that Lisp is designed around the idea of "bottom-up" programming where you are actually making layer upon layer of extensions to the language, each one incrementally more specific to the domain you're working in. That final top level that the application code is actually written with is a collection of functions that are highly specific to the exact application you're writing. Therefore, you actually have several layers of Domain-Specificity (could be a word), and if you want to write a similar application that uses the same data or the same concepts you already have a "dialect" of lisp written specifically to address your problem.
Good post, Mike.
Preach on, Ethan! Lisp-ers represent! (Throws up hands in the shape of parentheses.)
If anyone is curious about the bottom-up language-extending style he refers to, On Lisp by Paul Graham is a good source.
Of course, when he says "to the extent that the option to use Lisp has been present", that really is quite a significant qualifier. Indeed the option to use Lisp is usually not present in "mainstream software development". If it were, the Ruby community would not be walking around acting as though they invented meta-programming :)
Allow me to quote Peter Christensen: "My definition of mainstream is that you can use it at work without having to start your own company."
This is why people like me get excited when we manage to squeeze even the smallest degree of DSL-ness into Über-mainstream languages like Java.
Yes, Ethan. I remember when I coded Lisp for my AI class that I was quite excited about the conceptual worlds we could create. Those conceptual worlds grew to be DSL in a functional nature.
Ray, LOL! Nice. :)
My pleasure. I am glad it serves well. :)
Post a Comment