Designing functional and fluent API: example of the Visitor Pattern by José Paumard

Among the patterns from the GoF, the Visitor is probably the more complex to implement. One of the difficulties is that you need to implement it in your object model, leading to complex refactoring for legacy applications.

Based on the use of all the nifty tools brought by functional programming: chaining, composition, and partial application, you can implement Visitors without having to change your object model, using a functional and fluent API.

This approach can be used to implement other patterns: Builder and Validator. Using this way of designing API leads to readable and robust code, designed following the GoF patterns.

Passionate about programming computers for over 20 years, Jose made his debut in assembler and C, C for SIMD parallel machines before adopting Java as an object-oriented language, indispensable to most major modern applications. He brings his expertise and capacity for analysis and synthesis to many projects, mainly in the lower layers, close to the data, but also on complex UI design, or in the browser. PhD in applied maths and computer science, assistant professor in Paris North University for 20 years, Java Champion, Java Rockstar, Jose also has a passion for education and knowledge transfer. He gives talks in major international Java conferences (JavaOne in San Francisco, Devoxx in Antwerp, Paris and London). He wrote numerous technical articles on Java technologies for Java Magazine, Oracle Technolgy Network. He writes a blog, Java le soir, French documentary source on Java technologies for thousands of french speaking developers around the world. He is a member of the french Paris Java User Group, and has been a co-organizer of the conference Devoxx France for three years.

[KING]

Absolutely bonkers! Love it and hate it at the same time.

Thankfully, starting with Java21 and type-pattern matching visitors can be replaced with switch expressions. Additionally, if sealed classes/interfaces are used, it can offer a compile-time guarantee that all subtypes in the hierarchy have been properly taken care of. Unlike here, where visiting logic is placed in the registry and only breaks at run-time. And with NPE, of all things!

Nonetheless, video offers a lot of neat tricks for functional and fluent APIs. I'll surely use them either for builders or custom assertion classes for AssertJ.

[andreidei]

this talk should be entitled "insane people code like this"...

[badpotato]

this is Nice video.
it is a different way of solving a problem

[ruixue]

1:30 why Visitor Pattern
3:28 code demo
3:37 the Visitor Pattern has to visit some *graph* object

[nithinvarghese]

Great Video Learned a lot and a lot of tricks are now in my sleeve !! . Thank you soo much
34:52 In the Interface X<R>, How can one call define method type() as an instance value out of it, Can anyone share info or notes on the same?

[TJ-hsqm]

9:06 vp violates the GOF rule to never depend on concrete types, only on abstractions. How do you inject MockBody for Body in a test if the code depends on concrete types?

[anber]

i hope nobody writes this kind of code in production