Pure Functions and Immutable Objects
summary
Argues that isolating a functional core of pure functions and pushing I/O and side effects to an imperative shell makes logic referentially transparent, easier to test, parallelize, and refactor (replace temp with query, inline parameters, split phase). Recommends Java tooling: use Hibernate embeddables for immutable subobjects, Lombok value or records, and IntelliJ’s Analyze Data Flow to Here. Notes tradeoffs: validate immutables at construction, avoid cloning collections wildly, GC handles many small immutables but avoid them if you create millions per second. Only one of ~50 companies fully persists immutable entities.
AI-written summary · about
chapters (16)
- 0:00Introduction and speaker intro
- 2:10Signs of impure functions
- 3:57Pure vs impure functions
- 6:43Pure function quiz
- 10:51Benefits of pure functions
- 13:21Trust and purity in teams
- 15:07Functional core and imperative shell
- 19:01Mutable vs immutable objects
- 22:47Immutable class design
- 26:14Why final classes are unnecessary
- 28:05Breaking down large objects
- 30:36When to use immutable objects
- 32:00Immutable objects in workflows
- 33:48Returning multiple values
- 34:49Performance of immutable objects
- 36:14Key takeaways and summary
related talks
34mThe Hitchhiker Guide to Pure Functions and Immutable Objects
52mImmaculate Code (pure code)
51mFunctional Principles for Object Oriented Development
49mFunctional Core for a Side-Effect-Free Application Core
46mDesigning Functional Programs
34mFunctional Programming Anti-Patterns in Java
01h 00mImperative vs Functional: Which one to Choose?
01h 44mFunctional Programming: Technical Reasons to Adapt