From OOP to FP : the validation case

From OOP to FP
✅ The Validation case
Emmanuel Nhan - JUG Toulouse 11 juin 2019

😡 😡 😡 🤬
Let’s see the code…

💡There gotta be a
better way ! 🤔

Sticking in Javaland ☕
• Standard is JSR 303 : Bean Validation

• Let’s give it a try: Fortunately it is built-in in Spring !

JSR 303 results : the good
( Accumulates the errors for us in (found that in the docs):

Set<ConstraintViolation<…!>>
( Automatic 400 Bad Requests (although this is mostly
done by Spring)

( Support for basic use cases

JSR 303 results : the bad
) No support for the parse error of HostAndPort

) Need custom handling for inter-dependent ﬁelds

) Annotations are not type-checked

) Weird mix of custom/covered cases

) Smelling reﬂection down there…

JSR 303 results : the weirdo
🤔 Automatic translation of error messages
Why is presentation even related to Validation ???

*

better way ! 🤔
(Again !!!)

Do It Yourself 🛠
Let’s go back to the essence of our problem…

Validating one
• Result of a validation is either an error or a value

• Validation is just the function producing that result

• It looks like Optional structure but with an error type

• We need a way to use the validated result

Validated ✅ (Kotlin style)
sealed class Validated<E, V> {
data class Valid<E,V>(val value: V) :
Validated<E,V>()
data class Invalid<E, V>(val error: E):
Validated<E, V>()
}

So far…
We can :

• create a Validated with success with Valid(a)

• create a Validated with error with Invalid(e)
• map over a Valid value

Representing errors
• Let’s use an ADT. In Kotlin :

sealed class AlertCreationError {
data class ThresholdATooLow(!/*!!...!*/):
AlertCreationError()
data class ThresholdCTooHigh(!/*!!...!*/):
data class ThresholdBNotGreater(!/*…!*/):
!// And so on
}

So far…
We can :


• ﬁx the type of ﬁeld validation to
Validated<AlertCreationError, T>

Validating many 🤔
• Finding a way to compose validation errors

• Finding a way to compose valid results
We need Composition !

Error Accumulation 📋
• JSR 303 used a Set

• When in error, we will at least have one element

• Let’s add some precision

NonEmpty*
• Two types exists

• NonEmptyList (NEL)

• NonEmptyChain (NEC)

• Structures which look like a linked list  
but which contains at least one element

• Ensuring this condition via smart constructor

Keeping Validated generic
• We need the E type in Validated<E, R> to be
combinable

• That is a function combine: (E, E) !-> E
• In the jargon, it is called Semigroup

• We need to go from 
Validated<E, R> to Validated<Nel<E>, R>

So far…
We can :


• lift the error type from E to Nel<E> (leftMap)

Validating many
• Validating field A is independent of validating field B

• We need a function, with the shape :

(F<A>,F<B>,(A,B) !-> C) !-> F<C>
• Where F is a type like ValidatedNel with a fixed type: 
(ValidatedNel<E,A>,ValidatedNel<E,B>, 
(A,B) !-> C) !-> ValidatedNel<E, C>
• In the jargon, this is called Applicative

So far…
We can :


• lift the error type from E to Nel<E> & accumulate errors

• Combine all values when all ﬁelds are in Valid state
• Keep invalid when at least one ﬁeld is in Invalid state

Take away 🥡🍜
Validation is a (simple) problem which can be solved with
just 2 things :

✓Appropriate data structures (some may say ADT)  
to model errors & validation results

✓An abstraction to express independent computations
(Applicative)

better way ! 🤔
(Again & again !!!)
This is nice and all but…

Can we go further ? 🚀
💡We could try to make impossible states unrepresentable
possible
values for A
acceptable
values for A
acceptable
values for A
Validation :
Uses a predicate to determine
the acceptable subset of A
Is it possible to encode this in code ?

Type system ✨
• Predicate encoding in the type system

• Compiler automatic derivation

• There is this thing called Reﬁned

• Let’s see some (hardcore) Scala…  
(sorry I’m not ﬂuent in Haskell 🙊)

Not there yet ! 💫
• Clearly I’m not an expert (but if you are, let’s talk 🤩)

• Even for a simple case like Validation research is
important

• Mathematics are the (best) base tool at hand

Q&A time
Thanks for listening

@enhan on Github &
@nhanmanu on Twitter

References & credits
• Code:

• https://github.com/enhan/oop-to-fp-validation

• https://github.com/enhan/reﬁned-validation

• Articles:

• https://typelevel.org/cats/datatypes/validated.html

• https://arrow-kt.io/docs/arrow/data/validated/

• https://www.enhan.eu/how-to-in-fp/

• http://lara.epﬂ.ch/~kuncak/papers/
SchmidKuncak16CheckingPredicate.pdf

• Books:

• Functional Programming in Scala (Paul Chiusano and
Runar Bjarnason)

• Category Theory for Programmers (Bartosz Milewski)

• Libs:

• Spring: https://spring.io/

• Arrow: https://arrow-kt.io/

• Cats: https://typelevel.org/cats/

• Reﬁned: https://github.com/fthomas/reﬁned

• Pictures (all from unsplash, in order) :

• SpaceX

• Anthony Cantin

• Mirko Blicke

• Simon Caspersen

• Alexey Sukhariev

• Designecologist

From OOP to FP : the validation case

More Related Content

What's hot (20)

Similar to From OOP to FP : the validation case (20)

Recently uploaded (20)

From OOP to FP : the validation case