OOP -> FP mindshift

The foundation of Functional Programming

Behind the language syntax

The way of thinking about real or abstract

entities

their relationships

and communications between eachother

???


The Paradigme

The Anonymous function powered by

λ

The λ expression allows us dynamically create:
functions and lexical scope

Functions as a first-class citizen


First-class function is a function that can be:
passed | returned | stored
as ANY other data without
ANY syntactic restrictions

Higher order functions

Technically is a function that takes as a argument other function/s

We gain: Computation extracting (Divide & Conquer) and
Function composition availability (DRY)

Closures and Partial Application together

Enclosing ANY data inside the lambda function.

Partial Application - give a second thought


result = f(x)(y)(z)
<=>
f1 = f(x) =>
f2 = f1(y) =>
f2(z) = result

Currying

in context of Partial Application

map, filter, fold/l/r - What they have in common?

¿¿¿Anybody???

¡Recursion!

These Higher Order Functions abstracts away common patterns of recursion.

def filter(p: Int => Boolean): List[Int]
def map[A,B](fa: F[A])(f: A => B): F[B]
def flatMap[A,B](fa: F[A])(f: A => F[B]) : F[B]
def fold[A1 >: Int](z: A1)(op: (A1, A1) => A1): A1

Part I => Checkpoint

=> lambda and lexical scope

=> first class functions

=> higher order functions

=> partial application, currying, closures

=> function composition/chain

Part II

Functional domain modeling

Data structures just are. They don`t do anything.
Joe Armstrong, Erlang creator.

Before immutablity...


CorrectState ∈ { (x , y), (x’, y’) } ErrorsState ∉ { (x’, y), (x , y’) }

(Pure , Total , Deterministic)
=>

Referencial transparency

Data modeling FP approach

ADT - Algebraic Data Types

					
						// ADT :: Product Type
						case class Status(code: Int, statusMessage: String) 
						// ADT :: Sum Type
						sealed trait Result
						object Success extends Result
						object Failed extends Result 
						// ADT :: Exponential Type
						type aFunctionalType = Status => Result
						// Partial Type Application via alias
						type T[A] = Option[Map[Int, A]]
						val t: T[String] = Some(Map(1 -> "abc", 2 -> "xyz"))

OOP <=> encapsulate/couples state and behaviour.

FP <=> decouple them.

"Good OOP is nothing more then FP in disguise."

"Design patterns are for fill the gap of the OOP abstractions lack."

"With the power paradigm you don`t need any framework for DI."

"In FP it is a common practice to compose and build computation pipelines and defer evaluation until the end."

"In FP it is easy, and expected, to factor out common functionality into generic, reusable components that can be composed each other."

"Data structures just are. They don`t do anything."


But... Where IS the power of FP that we talk about?!

Everything is around Context!

The comprehension of for-comprehension expression

For-comprehension - a syntactic sugar for combination flatMap(s)/map together in a readable form

Putting it all together

DI in a functional way

¡doItHereTogether!

The last Milstone: For-Comprehension

Checkpoint Part II

=> OOP Application is a squence of statmens written in imperative way where each statments is changing the program state.

=> FP is a sequence of exrepssion written in declarative way where each expression represent a chain of transfromation without any chunks of mutability that could provoke hidden state change.

Takeaways

=> lambda and lexical scope

=> first class functions

=> higher order functions

=> partial application, currying, closures

=> function composition/chain

=> referencial transparency

=> ADT are power for domain/dsl modeling

Finish...

=> OOP Application is a squence of statmens written in imperative way where each statments is changing the program state.

=> FP is a sequence of exrepssion written in declarative way where each expressions represent a chain of transfromation without any chunks of mutability that could provoke hidden state change.

More and more about FP

=> Pattern Matching - power of the types

=> Type classes vs. Interfaces

=> Kinds - as a labels for the types

=> GADTs - Generalized ADT

=> Partial Type Application/Type Level Programming

=> A better Scala REPL ammonite.io

=> Typelevel CATS library

=> Scalaz Scalaz-ZIO

Scala -> (Haskell, Idris)

References

¡Muchas Gracias!

Thanks!