OOP => FP mindshift

The foundation of Functional Programming

Dawid Furman

Behind the language syntax

The way of thinking about real or abstract

entities

their relationships

and communications between eachother

???

The Paradigme

> Q: What is the BIG impact for the programming language syntax?
> E: The syntax is not on the main stage
> E: The syntax is a tool for realize our percetions and thinking about the code
> E: This mindset creates our imagination and constraints for the realizaiton. > E: This mindset create and restrictions and some kind of the border of the World.

The Anonymous function powered by

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

0. Milstone => The lambda function

Methods => 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 function

Closures, 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/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/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 together

Data 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]

5 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!

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.