Pure functions and immutable objects @dev nexus 2021

victor.rentea@gmail.com ♦ ♦ @victorrentea ♦ VictorRentea.ro
The Hitchhiker Guider to

Victor Rentea
Best Talks, Goodies, Blog:
VictorRentea.ro
Independent Trainer & Consultant
Founder of
Bucharest Software Craftsmanship Community
Java Champion
❤️ Simple Design, Refactoring, Unit Testing ❤️

Technical Training
Hibernate
Spring Func Prog in Java
300+ days
2000 devs
8 years
Training for you or your company: VictorRentea.ro
40 companies
Follow me:
35K 4K 3K
Java Performance
Reactive-X
Design Patterns
Clean Code
Refactoring
Unit Testing
TDD
any
lang

174 © VictorRentea.ro
a training by
Life

a training by
checkCustomer(customer);
checkOrder(customer, order);
Mock-full tests
Race Bugs
A method changes a parameter: Surprise!
Unexpected Different Results for Same Inputs
customer.setActive(true);
Temporal Coupling

a training by
do side-effects
return void sendEmail(Email):void
Command-Query Separation
setActive(true):void
return results
search(criteria):List
computePrice(flight):int
in 1994, by Bertrand Meyer
Pure Functions

a training by
No side effects
No INSERTs, POSTs, queues, files, fields,…
= 𝑀𝑎𝑡ℎ𝑒𝑚𝑎𝑡𝑖𝑐𝑎𝑙 𝐹𝑢𝑛𝑐𝑡𝑖𝑜𝑛𝑠: 𝑓 𝑥, 𝑦 = 𝑥2
+ 𝑦
(logging doesn't count)
Referential Transparent
Same Inputs ➔ Same Output
No current time, random, GET, SELECT…
≠ Idempotent
Pure Functions

a training by
Referential Transparent Idempotent
≠
f(1,2) = 3
f(1,2) can be replaced with 3 everywhere
After calling f once
Calling it again n times
will not produce any extra changes
Can Have Side Effects
eg: DELETE FROM X WHERE ID =
f(1,2)
f(1,2)
f(1,2)

a training by
Pure Functions : Quiz
f1(int x) {return x + 1;}
f2(Data d) {return ++d.x;}
f3() {d.incrementX(); return d.x;}
f4() {return querySQL(...);}
f5(int y) { return this.x + y; }
f6(Data d, int y) { return d.getX() + y; }
f7(int i) { if (i<0) throw new WrongInputException(); }
is this immutable?
Probable side effects
Expected to be pure

a training by
throw new E(); is pure
f(x) {
try {
//
}
}
catch (E) is pure?
if it always throws for the same inputs
it depends ...
* Some slightly disagree
on E
NO, if E can happen randomly
eg. IOException, OutOfMemory
YES, if E is thrown deterministically*
➔ Catch unexpected exceptions
in the outskirts of your code

a training by
Why we Love Pure Functions
➢No hidden inputs, only plain-sight return values and parameters
➢Easier to understand
➢No temporal coupling
➢Testable with less setup
➢Fast & Composable: free to call them n times ➔
➢Parallelizable
(careful with instance functions on mutable objects)
r=f();
a=g(r);

a training by
Replace Temp Variable with Query
If a function is pure + fast, it's safe to call it multiple times:
Replace Parameter with Query
var data = f(a,b);
data
data
f(a,b)
f(a,b)
big(..., f(a,b));
param
param
void big(..., param) {
f(a,b)
f(a,b)
they typically are

a training by
you don't care how many times
(and if) you call a pure function

a training by

a training by
That's it!
I'll make all my functions pure
that's usually impossible
What kind of app doesn't change anything?

a training by
In Java there's no way to strictly enforce purity
➔ We have to live with both pure and impure functions
How do we distinguish them?

a training by
do side-effects
return void sendEmail(Email):void
Command-Query Separation
setActive(true):void
return results
pure functions
search():List
computePrice(movie):int
Highlight Side Effects
computePriceAndAdjustMetrics(movie):int

a training by
You can do better!

a training by

a training by
functional core
Side-effects (Writes) +
Non-deterministic Reads
Expose them
Purify the most complex parts of your logic!

a training by
Purify the most complex parts of your logic!

a training by
Purifying Logic
Time and Random
Amount of time-dependent logic:
➢None (e.setCreationDate(now());) ➔ tolerate
➢Very little ➔ Inject a Clock / TimeProvider
➢Heavy (x-rare) ➔ expose a ..., time); parameter

a training by
No Files in Functional Core

a training by
Initial Read
Intermediary
(conditional?)
➔ Pass as Parameters
➔ Split-Phase Refactor f();
r=read();
f(r);
Writing Results ➔ Return Changes w=f();
persist(w);
r=read()
Expose DB and HTTP calls
imperative shell

a training by
Expose DB and HTTP calls
Initial Read
Intermediary
(conditional?)
➔ Pass as Parameters
➔ Split-Phase Refactor
r=read();
f(r);
r1=phase1(...)
phase2(r,r1...)
expose impurity
Writing Results ➔ Return Changes w=f();
persist(w);
r=read()
imperative shell
Create new classes 💪

a training by
Implement most complex logic
as internal pure functions
exposing impurity to the surface

a training by
Pure Functions don't
Change Objects' State
Immutable Objects

a training by
Immutable Objects

a training by
void f(Data data) {
...
if (data.getX() == 1) {
// will this run ?
}
}
void h() {
Data data = new Data(1);
obj.setData(data);
g(data);
}
obj
void g(Data data) {
data.setX(2);
mutateParam(data);
obj.mutateField();
f(data);
}
void setData(Data data) {
this.data = data;
}
void mutateField() {
this.data.setX(2);
}
same obj
in h() and g()
void mutateParam(Data data) {
data.setX(1);
}
x=
Long-lived mutable data
A Code Inspection Session
What code ran before,
having a reference
to my data instance?!
Mutable Data
...
...

a training by
void f(Data data) {
...
// will this run ?
}
}
void h() {
obj.setData(data);
g(data);
}
obj
void g(Data data) {
data.setX(2);
mutateParam(data);
obj.mutateField();
f(data);
}
void setData(Data data) {
this.data = data;
}
void mutateField() {
this.data.setX(2);
}
same obj
in h() and g()
void mutateParam(Data data) {
data.setX(1);
}
x=
Long-lived mutable data
What code ran before,
having a reference
to my data instance?!
Mutable Data
Immutable Data
...
...

a training by
void f(Data data) {
...
// will this run ?
}
}
void g(Data data) {
f(data);
}
void h() {
g(data);
}
Immutable Data
Who created
the instance?!
Easier to trace
data changes
x=

a training by
Designing Immutable Classes
public class A {
private final String s;
private final B b;
private final List<String> list;
public A(String s, B b, List<String> list) {
this.s = s;
this.b = b;
this.list = new ArrayList<>(list);
// validation ...
}
public List<String> getList() {
return unmodifiableList(list);
}
// getters
// hashCode, equals on all fields = Value Object
// bits of LOGIC 💪
public A withS(String newS) {
return new A(newS, b, list);
}
}
Mutates by creating a new instance
Stops creator keeping a reference
Overkill, as problem is not the creator but the "man-in-the-middle"
Oh, so
we CAN mutate them!
@lombok.With
Iterable<String> getList() {
List<? extends String> getList() {
or
final fields,
but not strictly required
record
(java 15)
Java collections are mutable😞
final
Afraid of hackers? 😨
@lombok.Value
or, until then...

a training by
Oh, so
we CAN mutate them!

a training by
A function changing an immutable object has to return it:
data = updx(data);
Imagine data
has 20 fields
... every time
data = updy(data);
data = updz(data);
The mess is still here!
🎵 Who changed the field X?
How to fix?

a training by
data = updx(data);
data = updy(data);
data = updz(data);
final variables won't allow this
IntelliJ underlines
reassigned variables ❤️
By the way, there are ways to add final automatically at code cleanup
Real Problem
Too Large Immutable Objects
data.xyz = createXYZ(...);
➔ break them
If they change together,
they stick together
= clutter; Extreme:
Mark only the non-final with @Var
(errorprone Java compiler from Google)

a training by
Wait a second,
I know...

a training by
void f(VO[] arr) {
arr[0] = arr[0].withX(-99);
}
void f(List<String> list) {
list.removeIf(String::isBlank);
}
void f(Map<Integer, VO> map) {
map.put(1, map.get(1).withX(-99));
}
map.get(1).withX(-99)

a training by
Don't
ever
mutate
collections!
➔ Create new ones

a training by
Why we Immutable objects
Easier to trace data changes
Can enforce validation in constructor
Safe to put in Set or Map(as keys)
Thread-safe ➔ no race bugs, since they can't be changed
➔ their hashCode
doesn't change

a training by
All right cowboy!
Only immutable objects from now on!
usually that's too much!

a training by
instead,
Extract immutable Value Objects from their fields
Leaving the root Entity mutable
NO*
*there are few cases when it pays to, but those apps typically don't persist their data
Should Entities be immutable?

a training by
@Entity
(mutable)
Persistent
Immutable Leaf
eg. FullName
Immutable Objects in Real Life
Non-Persistent
Runtime Objects
that you write heavy logic with
continuously break
Large Entities
@Embeddable

a training by
Non-Persistent
Runtime Objects
that you write heavy logic with
Always Immutable

a training by
The Big Deal

a training by
The Big Deal
Don't mutate objects on long workflows!
a(e) b(x) c(x) d(x) e(x) f(x) g(e) {
e.setField(...);
}
a(e) {
String s = b(vo);
e.setField(s);
}
b(…) c(…) d(…) e(…) f(…) g(…) {return ...;}
1) vavr.Tuple3<String,String,Integer>
2) NewConceptVO #kudos if you can find a good name!
can be pure functions
Immutable Arguments
Return the change to the surface, and apply it there
Return multiple changes:

a training by
The Big Deal
Is when immutable objects travel lots of code

a training by
Performance of Immutability

a training by
Concerned of Performance?
Measure it !
(and you might have a surprise)

a training by
Avoid Immutable Objects If
- Trashing millions of instances/second
- Cloning Lost of Collections
- Trivial logic (overkill)
- Persistent Entities or DTOs

a training by
Take-Aways
➢ Complex logic ➔ pure functions using immutable objects
➢ Functional Core / Imperative Shell
➢ Pull impure remote/DB calls in the shell
➢ We'll change it in there ➔ compute and return
➢ Without proper mindset, immutability can hurt
➢ Don't mutate: argument state, variables or collections
➢ Immutable: runtime data or persistent leaves
➢ We'll change it in there ➔ compute and return
And no, I'm against OOP; but not in huge logic code ➔

a training by
victorrentea@gmail.com ♦ ♦ Training: VictorRentea.ro
➢We'll change it in there ➔ compute and return

Pure functions and immutable objects @dev nexus 2021

More Related Content

What's hot

Similar to Pure functions and immutable objects @dev nexus 2021

More from Victor Rentea

Recently uploaded

Pure functions and immutable objects @dev nexus 2021