OOP => FP mindshift
The foundation of Functional Programming
Behind the language syntax
The way of thinking about real or abstractentities
their relationships
and communications between eachother
???
The Paradigme
The Anonymous function powered by
λ
The λ expression allows us dynamically create: 1. functions 2. the scope (a lexical scope)
0. Milstone => The lambda functionMethods => Functions
That difference lying behind the paradigm
1 Milstone => methods are NOT functions AND function literals can be assigned to val(ue)Functions => First class functions
A functions that can be: 1. passed as a argument 2. returned as any other data.
Higher order functions
Another fancy and cool name
Technically is a function that takes as a argument other function/s
Extract the computation - sounds like good old practices Divide & Conquer and DRY. 1 Milstone => Higher and first class functionClosures, Partial Application, and Currying together
Enclose a first class functions inside the lambda function.Partial Application - give a second thought
result = f(x)(y)(z)
<=>
f1 = f(x) =>
f2 = f1(y) =>
f2(z) = result
2. Milstone => Currying make multiple parameter group real!
Currying
in context of Partial Application
3. Milsone => Partial Application is a tool for a functions pipelines/chainmap, 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[B](f: Int => B): scala.collection.TraversableOnce[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...
Programs are just a collection of functions should:
Pure => never ever changing state/s == no side effects
Total => returns values for all inputs
Deterministic => returns the same result for the same input
4. Milstone => Referencial transparency = put all traits togetherData modeling OOP vs. FP approach
OOP <=> encapsulate/couples state and behaviour
class Status{
private int code;
private String statusMessage;
}
class Status (var code: Int, var statusMessage: String)
FP <=> decouple them.
case class Status(code: Int, statusMessage: String)
Data modeling FP approach
ADT - Algebraic Data Types
Where is the bridge between ADT: 1. Math => ¡Cardinality! 2. Immutablity => (Encapsulation by definition, Isolation by single source of truth, Immutable state of transfer)
"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 defere 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."
But... Where IS the power of FP that we talk about?!
Everything is around Context!
The comprehension of for-comprehension expression
// This signature is only for the List
def flatMap[B](f: Int => List[B]): List[B]
Putting it all together
DI in a functional way
The last Milstone: For-ComprehensionCheckpoint 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.
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
=> A better Scala REPL ammonite.io
=> Typelevel CATS library
=> Scalaz Scalaz-ZIO
Scala -> Haskell
References
¡Málaga Scala Developers!
¡Muchas Gracias!
