Principles of Fluent API Design
summary
Defines cascading API as chainable calls that may split across statements and fluent API as a style that guarantees a single unbroken expression, then gives concrete design choices: homogeneous vs heterogeneous return types, immutable vs mutable chains, and whether terminal steps are fallible. Notes real examples: Truth is heterogeneous and immutable, Flogger is mutable and homogeneous and uses parameterized no‑ops to avoid splitting. Calls out a common bug: Stream.parallel has no parameter so it forces splitting, and recommends escape hatches and runtime checks when splitting would break correctness.
AI-written summary · about
chapters (11)
- 0:00Fluent API design intro
- 1:06What defines a fluent API
- 5:21Cascading vs fluent API
- 6:05Why fluent APIs matter
- 7:29Design choices for fluent APIs
- 10:42Fluent utility pattern
- 13:32Comparing fluent API designs
- 14:18Benefits and trade-offs
- 15:22Pitfalls and constraints
- 16:46Quick tips for fluent APIs
- 17:29Q&A
related talks
46mDesigning Functional Programs
49mLet's make a contract: the art of designing a Java API
49mJava Functional Programming Idioms
27mModern Java API Design
56mJava Functional Programming Idioms
42mPure Functions and Immutable Objects
51mLet's make a contract: the art of designing a Java API
50mThe Good, the Bad and the Ugly of Java API Design
