FP 4 OOP FTW!

Functional Programming
for Object-Oriented
Programming
– for the Win!
Kevlin Henney

functional
programming
higher-order functions
recursion
statelessness
first-class functions
immutability
pure functions
unification
declarative
pattern matching
non-strict evaluation
idempotence
lists
mathematics
lambdas
currying
monads

When it is not
necessary to
change, it is
necessary not
to change.
Lucius Cary

public class Date implements ...
{
...
public int getYear() ...
public int getMonth() ...
public int getDayInMonth() ...
public void setYear(int newYear) ...
public void setMonth(int newMonth) ...
public void setDayInMonth(int newDayInMonth) ...
...
}

public class Date implements ...
{
...
public int getWeekInYear() ...
public int getDayInYear() ...
public int getDayInWeek() ...
public void setYear(int newYear) ...
public void setMonth(int newMonth) ...
public void setWeekInYear(int newWeek) ...
public void setDayInYear(int newDayInYear) ...
public void setDayInMonth(int newDayInMonth) ...
public void setDayInWeek(int newDayInWeek) ...
...
}

public final class Date implements ...
{
...
public int getWeekInYear() ...
public int getDayInYear() ...
public int getDayInWeek() ...
...
}

{
...
public int year() ...
public int month() ...
public int weekInYear() ...
public int dayInYear() ...
public int dayInMonth() ...
public int dayInWeek() ...
...
}

Immutable Value
References to value objects are commonly distributed and
stored in fields. However, state changes to a value caused
by one object can have unexpected and unwanted side-
effects for any other object sharing the same value
instance. Copying the value can reduce the
synchronization overhead, but can also incur object
creation overhead.
Therefore:
Define a value object type whose instances are immutable.
The internal state of a value object is set at construction
and no subsequent modifications are allowed.

{
...
public void nextDay() ...
public void addDays(int numberOfDays) ...
...
}

{
...
public Date nextDay() ...
public Date addDays(int numberOfDays) ...
...
}

{
...
public Date dayAfter() ...
public Date daysAdded(int numberOfDays) ...
...
}

Referential transparency is a very
desirable property: it implies that
functions consistently yield the same
results given the same input,
irrespective of where and when they are
invoked. That is, function evaluation
depends less—ideally, not at all—on the
side effects of mutable state.
Edward Garson
"Apply Functional Programming Principles"

Idempotence is the property of certain operations in
mathematics and computer science, that they can
be applied multiple times without changing the
result beyond the initial application.
The concept of idempotence arises in a number of
places in abstract algebra [...] and functional
programming (in which it is connected to the
property of referential transparency).
http://en.wikipedia.org/wiki/Idempotent

Asking a question
should not change
the answer.
Bertrand Meyer

Asking a question
should not change
the answer, and
nor should asking
it twice!

Immutable Value
Define a value object type
whose instances are immutable.
Copied Value
Define a value object type
whose instances are copyable.

class date
{
public:
date(int year, int month, int day_in_month);
date(const date &);
date & operator=(const date &);
...
int year() const;
int month() const;
int day_in_month() const;
...
void year(int);
void month(int);
void day_in_month(int);
...
};

class date
{
public:
date(const date &);
...
int year() const;
int month() const;
...
void set(int year, int month, int day_in_month);
...
};
today.set(2015, 3, 24);

class date
{
public:
date(const date &);
...
int year() const;
int month() const;
...
};
today = date(2015, 3, 24);

Many objects have no conceptual
identity. These objects describe
some characteristic of a thing.

When you care only about the
attributes of an element of the
model, classify it as a VALUE
OBJECT. Make it express the
meaning of the attributes it
conveys and give it related
functionality. Treat the VALUE
OBJECT as immutable. Don't give
it any identity and avoid the
design complexities necessary to
maintain ENTITIES.

A type hierarchy is composed of subtypes and
supertypes. The intuitive idea of a subtype is one
whose objects provide all the behavior of objects
of another type (the supertype) plus something
extra. What is wanted here is something like the
following substitution property: If for each
object o1 of type S there is an object o2 of type T
such that for all programs P defined in terms of T,
the behavior of P is unchanged when o1 is
substituted for o2, then S is a subtype of T.
Barbara Liskov
"Data Abstraction and Hierarchy"

public class Ellipse
{
private double semiMajor, semiMinor;
public Ellipse(double a, double b) ...
public double semiMajorAxis() ...
public double semiMinorAxis() ...
public void semiMajorAxis(double a) ...
public void semiMinorAxis(double b) ...
...
}
public class Circle extends Ellipse
{
public Circle(double r) ...
public double radius() ...
public void radius(double r) ...
...
}

{
...
public void semiMajorAxis(double a) ...
...
}
{
...
@Override
public void semiMajorAxis(double a)
{
throw new UnsupportedOperationException();
}
@Override
...
}

The reason a solution is so hard to come by is because the
problem is poorly stated: mathematics tells us that a circle is an
ellipse, so I can substitute a circle wherever an ellipse is required,
suggesting that a circle is a subtype of an ellipse.
Kevlin Henney
"Vicious Circles", Overload 8, June 1995

The troubles start when we introduce any state modifying
functions, such as assignment or the ability to change the major
and minor axes independently.
Kevlin Henney

The troubles start when we introduce any state modifying
functions, such as assignment or the ability to change the major
and minor axes independently.
We are so confident that we understand the mathematical
concepts behind circles and ellipses that we have not bothered to
ask any more questions of that domain.
Kevlin Henney

The first observation is that there is no way to change circles and
ellipses once you have created them.
Kevlin Henney

This is the correct mathematical model: there are no side effects
in maths, conic sections do not undergo state changes, and there
are no variables in the programming sense of the word.
Kevlin Henney

Readers who are comfortable and familiar with functional
programming and data flow models will recognise the approach.
Kevlin Henney

Readers who are comfortable and familiar with functional
programming and data flow models will recognise the approach.
In the case of circles and ellipses, the circle is simply an ellipse
with specialised invariants. There is no additional state and none
of the members of an ellipse need overriding as they apply
equally well to a circle.
Kevlin Henney

{
...
}
{
...
}

«interface»
UsageInterface
CommonCode
ConcreteLeaf ConcreteLeaf
Pure Interface Layer
Interfaces may extend
interfaces, but there is no
implementation defined in
this layer.
Common Code Layer
Only abstract classes are
defined in this layer, possibly
with inheritance, factoring out
any common implementation.
Concrete Class Layer
Only concrete classes are
defined, and they do not
inherit from one another.
ConcreteLeaf

public interface Ellipse
{
double semiMajorAxis();
double semiMinorAxis();
...
}
public interface Circle extends Ellipse
{
double radius();
...
}

public class ??? implements Ellipse
{
private double semiMajorAxis, semiMinorAxis;
...
}
public class ??? implements Circle
{
private double radius;
...
}

public class ??? implements Ellipse
{
private double semiMajorAxis, semiMinorAxis;
...
}
public class ??? implements Circle
{
...
}
The Naming of Cats is a difficult matter,
It isn't just one of your holiday games;
You may think at first I'm as mad as a hatter
When I tell you, a cat must have THREE DIFFERENT NAMES.
[...]
But above and beyond there's still one name left over,
And that is the name that you never will guess;
The name that no human research can discover—
But THE CAT HIMSELF KNOWS, and will never confess.
[...]
T S Eliot

{
...
}
public class Circle
{
public Ellipse toEllipse() ...
...
}

{
public boolean isCircle() ...
...
}

phenomenon (plural: phenomena): An
element of what we can observe in the world.
Phenomena may be individuals or relations.
Individuals are entities, events, or values.
Relations are roles, states, or truths.
individual: An individual is a phenomenon that
can be named and is distinct from every other
individual: for example, the number 17, George
III, or Deep Blue's first move against Kasparov.
relationship: A kind of phenomenon. An
association among two or more individuals, for
example, Mother(Lucy, Joe). Also, generally, any
pattern or structure among phenomena of a
domain.

Events. An event is an individual happening, taking
place at some particular point in time. Each event is
indivisible and instantaneous.
Entities. An entity is an individual that persists over
time and can change its properties and states from one
point in time to another.
Values. A value is an intangible individual that exists
outside time and space, and is not subject to change.
States. A state is a relation among individual entities
and values; it can change over time.
Truths. A truth is a relation among individuals that
cannot possibly change over time.
Roles. A role is a relation between an event and
individuals that participate in it in a particular way.

In computing, a persistent data structure is a data structure
that always preserves the previous version of itself when it is
modified. Such data structures are effectively immutable, as
their operations do not (visibly) update the structure in-place,
but instead always yield a new updated structure.
http://en.wikipedia.org/wiki/Persistent_data_structure
(A persistent data structure is not a data structure committed
to persistent storage, such as a disk; this is a different and
unrelated sense of the word "persistent.")

public interface RecentlyUsedList
{
static final RecentlyUsedList nil = new Null();
boolean isEmpty();
int size();
String get(int index);
RecentlyUsedList add(String newItem);
RecentlyUsedList remove(String toRemove);
}
RecentlyUsedList list =
nil.add("Alice").add("Bob").add("Alice");
assert list.size() == 2;
assert list.get(0).equals("Alice");
assert list.get(1).equals("Bob");

class Null implements RecentlyUsedList
{
public boolean isEmpty()
{
return true;
}
public int size()
{
return 0;
}
public String get(int index)
{
throw new IndexOutOfBoundsException();
}
public RecentlyUsedList add(String newItem)
{
return new Link(newItem, this);
}
public RecentlyUsedList remove(String toRemove)
{
return this;
}
}
class Link implements RecentlyUsedList
{
private final RecentlyUsedList next;
private final String item;
private final int size;
Link(String head, RecentlyUsedList tail)
{
next = tail;
item = head;
size = tail.size() + 1;
}
public boolean isEmpty()
{
return false;
}
public int size()
{
return size;
}
public String get(int index)
{
return index == 0 ? item : next.get(index - 1);
}
public RecentlyUsedList add(String newItem)
{
RecentlyUsedList removed = remove(newItem);
return
removed == next ?
this : new Link(newItem, removed);
}
public RecentlyUsedList remove(String toRemove)
{
if(item.equals(toRemove))
{
return next;
}
else
{
RecentlyUsedList removed =
next.remove(toRemove);
return removed == next ?
this : new Link(item, removed);
}
}
}

One of the most powerful mechanisms
for program structuring [...] is the block
and procedure concept.
A procedure which is capable of giving
rise to block instances which survive its
call will be known as a class; and the
instances will be known as objects of
that class.
A call of a class generates a new object
of that class.
Ole-Johan Dahl and C A R Hoare
"Hierarchical Program Structures"

public class HeatingSystem
{
public void turnOn() 
public void turnOff() 

}
public class Timer
{
public Timer(TimeOfDay toExpire, Runnable toDo) 
public void run() 
public void cancel() 

}

Timer on =
new Timer(
timeToTurnOn,
new Runnable()
{
public void run()
{
heatingSystem.turnOn();
}
});
Timer off =
new Timer(
timeToTurnOff,
new Runnable()
{
public void run()
{
heatingSystem.turnOff();
}
});

class Timer
{
public:
Timer(TimeOfDay toExpire, function<void()> toDo);
void Run();
void Cancel();
...
};

Timer on(
timeOn,
bind(&HeatingSystem::TurnOn, &heatingSystem));
Timer off(
timeOff,
bind(&HeatingSystem::TurnOff, &heatingSystem));

public class Timer
{
public Timer(TimeOfDay toExpire, Action toDo) ...
public void Run() ...
public void Cancel() ...
...
}

Timer on = new Timer(timeOn, heatingSystem.TurnOn);
Timer off = new Timer(timeOff, heatingSystem.TurnOff);

Timer on = new Timer(timeOn, heatingSystem::turnOn);
Timer off = new Timer(timeOff, heatingSystem::turnOff);

Timer on =
new Timer(timeOn, () => heatingSystem.TurnOn());
Timer off =
new Timer(timeOff, () => heatingSystem.TurnOff());

Timer on =
new Timer(timeOn, () -> heatingSystem.turnOn());
Timer off =
new Timer(timeOff, () -> heatingSystem.turnOff());

Timer on(
timeOn, [&]() { heatingSystem.TurnOn(); });
Timer off(
timeOff, [&]() { heatingSystem.TurnOff(); });

William Cook, "On Understanding Data Abstraction, Revisited"

Pluggable Behavior
How do you parameterize the behavior
of an object?
Using Pluggable Behavior is a much
better solution than creating a hundred
different subclasses, each differing from
each other in only one or two methods.
For simple behavior changes, use a
Pluggable Selector. A Pluggable Block
gives you more flexibility.

Use procedure arguments to provide
flexibility in an interface.
This technique can greatly simplify
an interface, eliminating a jumble of
parameters that amount to a small
programming language.
Butler W Lampson
"Hints for Computer System Design"

If you have a procedure with
ten parameters, you probably
missed some.
Alan Perlis

A simple example is an enumeration
procedure that returns all the
elements of a set satisfying some
property. The cleanest interface
allows the client to pass a filter
procedure that tests for the property,
rather than defining a special
language of patterns or whatever.
Butler W Lampson
"Hints for Computer System Design"

Enumeration Method
Some types of aggregate [...] have representations that do
not conveniently support Iterator-based traversal.
Similarly, using an Iterator approach to access the
elements of an aggregate that is shared between threads
can incur unnecessary overhead from repeated locking.
Therefore:
Bring the iteration inside the aggregate and encapsulate
it in a single enumeration method that is responsible for
complete traversal. Pass the task of the loop—the action
to be executed on each element of the aggregate—as an
argument to the enumeration method, and apply it to
each element in turn.

Lifecycle Callback
The lifecycle of some objects is simple: their clients
create them before they are used, they stay alive as
long as they are used, and they are disposed of by
their clients when no longer used. However, some
objects have a much more complex lifecycle, driven by
the needs and events of their component environment.
Therefore:
Define key lifecycle events as callbacks in an interface
that is supported by framework objects. The
framework uses the callbacks to control the objects’
lifecycle explicitly.

public interface IObservable<out T>
{
IDisposable Subscribe(IObserver<T> observer);
}
public interface IObserver<in T>
{
void OnCompleted();
void OnError(Exception error);
void OnNext(T value);
}
IDisposable subscription =
source.Subscribe(
value => handle element,
error => handle exception,
() => handle completion);

Observer
Consumer objects sometimes depend on the state of, or
data maintained by, another provider object. If the
state of the provider object changes without notice,
however, the state of the dependent consumer objects
can become inconsistent.
Therefore:
Define a change-propagation mechanism in which the
provider—known as the ‘subject’—notifies registered
consumers—known as the ‘observers’—whenever its
state changes, so that the notified observers can
perform whatever actions they deem necessary.

Event-Based,
Implicit Invocation
The idea behind implicit
invocation is that instead
of invoking a procedure
directly, a component can
announce (or broadcast)
one or more events. Other
components in the system
can register an interest in
an event by associating a
procedure with it.
Thus an announcement
"implicitly" causes the
invocation of procedures in
other modules.

Some people, when confronted with a
problem, think, "I know, I'll use threads,"
and then two they hav erpoblesms.
Ned Batchelder
https://twitter.com/#!/nedbat/status/194873829825327104

Shared memory is like a canvas where
threads collaborate in painting images,
except that they stand on the opposite
sides of the canvas and use guns rather
than brushes. The only way they can
avoid killing each other is if they shout
"duck!" before opening fire.
Bartosz Milewski
"Functional Data Structures and Concurrency in C++"
http://bartoszmilewski.com/2013/12/10/functional-data-structures-and-concurrency-in-c/

Mutable
Immutable
Unshared Shared
Unshared mutable
data needs no
synchronisation
Unshared immutable
data needs no
synchronisation
Shared mutable
data needs
synchronisation
Shared immutable
data needs no
synchronisation

Instead of using threads and shared memory
as our programming model, we can use
processes and message passing. Process here
just means a protected independent state
with executing code, not necessarily an
operating system process.
Russel Winder
"Message Passing Leads to Better Scalability in Parallel Systems"

OOP to me means only messaging,
local retention and protection and
hiding of state-process, and
extreme late-binding of all things.
It can be done in Smalltalk and in
LISP. There are possibly other
systems in which this is possible,
but I'm not aware of them.
Alan Kay

Languages such as Erlang (and occam before
it) have shown that processes are a very
successful mechanism for programming
concurrent and parallel systems. Such
systems do not have all the synchronization
stresses that shared-memory, multithreaded
systems have.
Russel Winder
"Message Passing Leads to Better Scalability in Parallel Systems"

Multithreading is just one
damn thing after, before, or
simultaneous with another.
Andrei Alexandrescu

Actor-based concurrency is
just one damn message after
another.

Sender Receiver A
Message 1Message 3
Receiver B
In response to a message that it receives, an actor
can make local decisions, create more actors, send
more messages, and determine how to respond to
the next message received.
http://en.wikipedia.org/wiki/Actor_model

Future
Services that are invoked concurrently on a component
may need to return a result to the calling client.
However, if the client does not block after calling the
service, continuing instead with its own computation,
the service’s result may not be available when the
client needs to use it.
Therefore:
Immediately return a ‘virtual’ data object—called a
future—to the client when it invokes a service. This
future [...] only provides a value to clients when the
computation is complete.

FP 4 OOP FTW!

More Related Content

What's hot (20)

Viewers also liked (17)

Similar to FP 4 OOP FTW! (20)

More from Kevlin Henney (20)

Recently uploaded (20)

FP 4 OOP FTW!