Fluent Interfaces Are Bad for Maintainability

http://www.yegor256.com/2018/03/13/fluent-interfaces.html

by ingve • 8 years ago

53 51 8 years ago

rjbwork• 8 years ago

I disagree with a few caveat - you need to go with the Interface Per Operation pattern, use a builder, and provide many parameters to your methods. You're guiding your user through the object building pipeline, so bonus points if you constrain them to only certain operations at certain points in the pipeline so that they don't shoot themselves in the foot.

wiradikusuma• 8 years ago

As a lazy user of libraries, I disagree.

Maybe there can be a middle ground, eg a fluid interface generator ala Lombok.

jpitz• 8 years ago

They (Lombok) are already doing so:

https://projectlombok.org/features/experimental/Accessors

> "Experimental because: We may want to roll these features into a more complete property support concept. New feature – community feedback requested. Current status: positive - Currently we feel this feature may move out of experimental status with no or minor changes soon."

Sharlin2• 8 years ago

That is the biggest problem with fluent interfaces—they force objects to be huge.

Only if your language doesn't support adding methods to types after the fact, like C# extension methods, Rust traits, or Scala implicits.

tdriggs• 8 years ago

Came to say the same thing. In Rust, you can also have fluent interfaces that return different types as you build, which means that you end up being more typesafe throughout the construction process.

snarfy2• 8 years ago

Even without that support, if you return interfaces instead of the concrete type each return can be a different implementation. There is no need to have one giant class. All of those methods in his example should return IJdkRequest, not JdkRequest.

Sharlin2• 8 years ago

That doesn't help at all because all the methods will still have to be declared in IJdkRequest and implemented by every concrete subtype returned by the methods.

usrusr• 8 years ago

Even in Java: if you want your fluent builder to be extensible, that's easy enough to achieve with a base class that returns a generic self type in the fluent methods. If lack of extensibility is the strongest criticism of fluency, then fluency must be great.

hvidgaard4• 8 years ago

I use extension methods extensively, and it keeps the code closer to where it's used and the classes they operate on clean. It's a huge win for maintainability.

cromwellian• 8 years ago

It seems most of the examples are builder-pattern like, constructing configuration for the final object. If that's the case, all you really need it something like @AutoValue or the @Value.Immutable from immutables.org

Most of the boilerplate is removed, especially with Immutables.org's annotation processor. Plus, you get immutability and other validation.

specialist• 8 years ago

Ya. Builder, Composite, Method Chaining implementations are (can be) isomorphic.

Thanks for the immutables.org link. Amazing. FWIW, I once fudged a UI DSL for AWT/Swing using annotations. It sucked. Too many edge cases requiring shims. Mostly because the underlying UI components were not designed for (clean) composition.

Like the OP, I went a little nutty with Fluent APIs for a while. Never again.

Now I prefer Builder for small stuff and DSLs for anything interesting. Composite & Intepreter is a potent combo.

Mister_Snuggles2• 8 years ago

While I don’t like Fluent interfaces at all, I don’t like the alternative presented much either.

My dislike of Fluent interfaces stems from two things. First, it’s trying to contort an English-like sentence out of a programming language, which just looks and feels wrong. It leads to weird methods like ‘.method’ in the example. Second, Fluent interfaces really try to paper over the fact that the language lacks an equivalent to Visual Basic’s ‘with’[0] statement.

On the other hand, the example presented is not great either. Should ResponseAssertStatus be an object? Wouldn’t it make more sense to do the request then have a separate line of code to evaluate the status? How does it make sense for BodyOfResponse to be constructed out of some kind of ResponseAssertStatus object?

Between the two options, the Fluent interface makes more sense, even if the underlying implementation ends up being kind of ugly.

[0] https://docs.microsoft.com/en-us/dotnet/visual-basic/languag...

braythwayt• 8 years ago

I second the notion that fluency is a language syntax problem that should not be solved with the design of interfaces.

Smalltalk also solved this problem with the semi-colon, but for some damn fool reason we followed C syntax but didn't find an alternative. And now we're trying desperately to replicate `&.` in every library and language, but we still don't have an easy way to write:

    someObject
      .doThis();
      .doThat();
      .dontForgetToFinishUp().

bonesss4• 8 years ago

    someObject
    |> doThis
    |> doThat Thing
    |> doThat OtherThing
    |> dontForgetToPayTheBill

    let getErDone = 
        doThis 
        >> doThat Thing 
        >> doThat OtherThing 
        >> dontForgetToPayTheBill

    someObject |> getErDone

[not just pseudo-code, that can be compiled with the right definitions]

mhomde• 8 years ago

I always wanted a language that was built upon the concept on just passing things forward in a pipe, and was like an hybrid between functional and c style languages, like:

  someobject => doThis() => doThat() => dontForgotToFinishUp()

then you could also possible send multiple objects into that pipe:

  obj1, obj2 => doThis() => doThat() => dontForgotToFinishUp()

you'd have to have some semantics for sending them separately, as an ienumerable or as parameters but perhaps that could be done

  (obj1, obj2) => doThis() => doThat() => dontForgotToFinishUp()

  [obj1, obj2] => doThis() => doThat() => dontForgotToFinishUp()

add on top of that something that could abstract away multithreading/tasking in certain cases (automatically assigning them to tasks) and I'd be a happpy coder :)

erpellan• 8 years ago

Kotlin solves the problem elegantly with the 'apply' and 'run' extension functions.

  fun foo() =
    Runtime.getRuntime().apply {
        addShutdownHook(Thread { println("Bye!") })
        traceMethodCalls(true)
        exit(404)
    }

oweiler• 8 years ago

With `Arrow`, a Kotlin FP library you can do that

"foo" pipe capitalize pipe toUpperCase pipe reverse

bonesss4• 8 years ago

While I don’t like Fluent interfaces at all, I don’t like the alternative presented much either

If you pull at this sweater thread the end result is working in a language powerful enough to model the 'human readable' bit as structured code, and let mini-DSLs flourish in code bases and interfaces... This may entail leaving OOP partially behind, but it's highly achievable (Scala, F#, Haskell, LISP, etc).

ken• 8 years ago

That feature is, of course, much older than Visual Basic. Pascal had "with" a couple decades earlier.

3pt141592• 8 years ago

Many times programmers do not even know that their language contains something akin or better than VB's `with` statement. For example, in Ruby `instance_eval` or the even more powerful `instance_exec` could be a drop in replacement for half the stupid fluent interface libraries out there.

The one exception I'll make is query builders like ActiveRecord, as the submitted post mentions. It's hard to figure out how else you can dynamically pass `User.where(age > 18)` to a controller that has the filter to only include men and to paginate by 10 records at a time. I'm not saying it's not possible, it just seems like the one case where the fluent interface is worth the pain it brings. Even so, I really hate them even if I love Rails. Also, scopes are so brittle I avoid them whenever possible. They seem clean and elegant at first, but they're hard to combine and that combining is really only needed as the application gets more and more complicated.

Mister_Snuggles2• 8 years ago

How do you feel about LINQ[0] (specifically, the query expression syntax) as an alternative to the query builders that you mention? From reading this page[1], I'd guess that the query expression syntax compiles down to the same code that the method-based syntax does.

I think it looks great, but I've never had a chance to actually use it. None of the languages that I use regularly have anything even close to LINQ's query expression syntax.

[0] https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

[1] https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

chopin• 8 years ago

I prefer to return different interfaces from each (or almost each) method. This way also a predefined order of calls is imposed which you may want sometimes. A predefined order also makes similar uses look similar which I deem a benefit as well.

jdmichal• 8 years ago

I was wondering why this suggestion wasn't included in the OP, as it's exactly the route that the JAX-RS client specs took. There are several interfaces, and some of the fluent calls are basically terminal by leading to one of the other interfaces.

It starts here with the `Client` interface:

https://docs.oracle.com/javaee/7/api/javax/ws/rs/client/Clie...

Which then leads to `WebTarget`, then `Invocation.Builder`, then `Invocation`. `Invocation` objects can then be executed to generate `Response` objects, or typed responses, depending on the overload used.

LeanderK• 8 years ago

I don't agree with the fundamental concern. I think sacrificing maintainability for ease of use is a valid thing to do.

Saving 100x 20 minutes in developer time for the library users for taking an hour more to implement a feature is a good trade.

Every rule has an exception, but fluent interfaces being bad for maintainability is often justified.

mcphage• 8 years ago

I think sacrificing maintainability for ease of use is a valid thing to do.

I agree. If you're not willing to make your developers' lives easier, then what are you doing writing a public library in the first place?

cs02rm0• 8 years ago

Yeah. It's a tool, use it in moderation when most appropriate and you should be ok.

Yegor often seems to take an extreme position, which makes for a good discussion especially as there's usually some truth in what he says but I suspect there are no silver bullets to find here.

hodgesrm• 8 years ago

Personally I like fluent interfaces because they enable IDE users to write correct code quickly. That's a big win in languages like Java.

The changes you make to enable fluent interfaces underneath are just boilerplate code that is unlikely to have errors or require much maintenance. At least that's my experience.

overgard2• 8 years ago

Honestly I think ease of use of a library is way more important than implementation elegance. How many people are ever going to look at your libraries source code? .001% of your users? I use the C++ stl every day, but if you look at the implementation it's basically horrifying, but I don't really care because the interface is straightforward and does its job.

My main issue with fluent interfaces though is you can end up with objects in weird half initialized states, and there's generally combinations of parameters that are incompatible which the type system can't help you with. The point of constructors is you don't end up with semi-initialized objects

jlg232• 8 years ago

Honestly I think ease of use of a library is way more important than implementation elegance. How many people are ever going to look at your libraries source code?

Poor idiots like me who get hired to help get the hard, last 10% done.

Given the small percentage of projects that actually have a lifespan of more than a few months, I'd still chose usability (by devs) over elegance for prototypes or MVPs, but one should never forget that this can incur a huge technical debt.

PS: I do not consider the article's proposed solution elegant - quite the contrary.

overgard2• 8 years ago

We probably don't disagree here, because "clever" interfaces generally annoy me, I just think in terms of priorities interface matters more than implementation elegance. A confusing implementation might waste a few people's time, but a bad interface can waste hundreds\thousands of peoples time. (if you ever worked with COM or Win32 apis you probably feel my pain)

jlg232• 8 years ago

I am not sure I want:

* HTTP-requests done in constructors

* Assertion classes that wrap objects of interest which in turn must be extracted from their wrapper

* Specific methods that assert that one very specific attribute has an equally specific integer value.

mcguire• 8 years ago

The before state may or may not be bad, but the after state is hideous. Multiply nested constructors?

crabl• 8 years ago

I like the "pipeable operators" approach that RxJS takes in order to prevent this. Each instance of an Observable has a ".pipe" method which can transform the observable stream in some way and returns an Observable (https://github.com/ReactiveX/rxjs/blob/master/doc/pipeable-o...).

It would also be nice to have an operator like the proposed "pipeline" operator, à la F# (https://github.com/tc39/proposal-pipeline-operator).

stickfigure• 8 years ago

This is horrifying. It prioritizes the ease of the library developer's life over the library user's life. That smart-object API is just simply painful to use.

Oddly enough, I (independently) developed a very similar opensource http library with fluent, immutable command objects:

https://github.com/stickfigure/hattery/

Of all the libraries I've built in my life, this is probably the one I enjoy using most. I also don't have any problems maintaining it; I still add features all the time (most recently, preflight and postflight functions) and it's still fun.

The reason it's easy to maintain, I suspect, is mostly two reasons: 1) everything is immutable and 2) there's clean separation between the Request and the Transport.

Fluent Interfaces Are Bad for Maintainability

Related Stories