OOP => FP mindshift

The foundation of Functional Programming

Dawid Furman

Perception and imagination

Reflexion about the programming paradigms

The way of thinking about real or abstract

entities

their relationships

and communications

each other to build

Types => Object => Relationships => Communications => Application Bounded Context

The Anonymous function powered by

The λ allows us dynamically create:
1. functions 2. scope (lexical scope)

Nil. Milstone: The lambda function.

Methods => Functions

I. Milstone: Methods are NOT Functions.

Functions => First class functions

A functions that can be: 1. passed or 2. returned as any other data.

Higher order functions

Another fancy and cool name

Is a function that can take as a argument: function/s (and | or) return a function.

Extract the computation - sounds like good old practices Divide & Conquer and DRY. II. Milstone: Higher and first class function.

Closures and Partial Application

Enclose a first class functions inside the lambda function. III. Understanding Partial Application.

Partial Application - give a second thought


								result = f(x)(y)(z) 

								<=> 

								f1 = f(x) =>

								f2 = f1(y) =>

								f2(z) = result

Currying make multiple parameter group real!

Currying

in context of Partial Application

IV. Partial Application as a tool for a functions pipelines/chain

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[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

Part II

Functional domain modeling

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

Before immutablity...

Referencial transparency is a consequence of having pure functions.

Pure functions never ever changing state/s.

so no unexpected sides effects.


							def pureFunction(oldState: A) : A = { 

								// no external references 

								A(a) 
 // new object  <=> represent state changing.
							}

Data modeling OOP vs. FP approach

OOP <=> encapsulate/couples state and behaviour


							// Java POJO - Mutable data structure

							class Status{ 

								private int code;
								private String statusMessage;
							}

							// Scala POJO 

							class Status (var code: Int, var statusMessage: String)

FP <=> decouple them.


							// ADT - Product Type - as a immutable data structure

							case class Status(code: Int, statusMessage: String)

"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."

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]

III. Milstone: 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!

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.