functional solid

131
Matt Stine Functional Soλid

Upload: matt-stine

Post on 10-May-2015

1.247 views

Category:

Technology


0 download

DESCRIPTION

As given at the St. Louis Java User Group on August 9, 2012.

TRANSCRIPT

Page 1: Functional solid

Matt Stine

Functional Soλid

Page 2: Functional solid

• Senior Consultant, PSOvFabric, Cloud Application PlatformVMware

• Speaker (JavaOne, SpringOne/2GX, CodeMash, NFJS, RWX, PAX, UberConf)

• Author (GroovyMag, NFJS the Magazine, Selenium 2.0 Refcard)

• Founder of the Memphis/Mid-South Java User Group

• Former Agile Zone Leader @ DZone

About your speaker...

Page 3: Functional solid

SOLIDPrinciples

FunctionalProgramming

Page 4: Functional solid

SOLIDPrinciples

FunctionalProgramming

Page 5: Functional solid

Pitch

• Software designs tend to rot.

• Design rot impedes our effectiveness.

• SOLID principles help treat design rot.

• Achieving SOLID designs is another reason to learn FP!

Page 6: Functional solid

Motivation

Page 7: Functional solid
Page 8: Functional solid

Trends

• How Software Systems Evolve

• Programming Paradigms

• The Quest for “Best Practices”

Page 9: Functional solid

The evolution of software...

Page 10: Functional solid

http://www.flickr.com/photos/unloveable/2400895854

http://www.flickr.com/photos/billselak/427719926

From simplicity to complexity...

Page 11: Functional solid

Software starts to rot like a

bad piece of meat.

“Uncle Bob” Martin

http://www.flickr.com/photos/thejcgerm/379082415

Page 12: Functional solid

We don’t handle change well...

Page 13: Functional solid

Unclear or incomplete change specifications...

Page 14: Functional solid

Extreme time pressure...

Page 15: Functional solid

Team members unfamiliar with original design/architecture...

Page 16: Functional solid

It smells!

Page 17: Functional solid

Rigidity

Page 18: Functional solid

Fragility

Page 19: Functional solid

Immobility

Page 20: Functional solid

Viscosity

Page 21: Functional solid

Needless Complexity

Page 22: Functional solid

Needless Repetition

Page 23: Functional solid

Opacity

Page 24: Functional solid

Programming Paradigms

Page 25: Functional solid

Programming eras...

• Structured Programming(late 1960’s - late 1980’s)

• Object Oriented Programming(mid 1970’s - present day)

• Functional Programming(early 1990’s - ???)

Page 26: Functional solid
Page 27: Functional solid

TH

E C

HA

SM

Page 28: Functional solid
Page 29: Functional solid

Accumulation of Knowledge?

Page 30: Functional solid

Accumulation of Knowledge?

Page 31: Functional solid

Paradigm Shifts

Page 32: Functional solid

http://www.gotw.ca/publications/concurrency-ddj.htm

Page 33: Functional solid

The Quest for

“Best Practices”

Page 34: Functional solid

• Which web framework should I use?

• Why are there so many persistence API’s?

• Which is better: Scala or Clojure (or Erlang)?

• How should I use design patterns?

• How do I build a good architecture?

Page 35: Functional solid

http://en.wikipedia.org/wiki/No_Silver_Bullet

Page 36: Functional solid

What are the FP best practices?

Page 37: Functional solid

The Perfect Storm

Page 38: Functional solid

TheSOLID

Principles

SRP OCP LSP

ISP DIP

Page 39: Functional solid

http://clojure.org

Page 40: Functional solid

http://www.infoq.com/presentations/SOLID-Clojure

Page 41: Functional solid

The Single Responsibility Principle

Page 42: Functional solid

A class (module) should have only one reason

to change.

Page 43: Functional solid

Tom DeMarco Meilir Page-Jones

COHESION

Page 44: Functional solid

Rectangle

+ draw()+ area() : double

GraphicalApplication

Computational Geometry Application

GUI

Page 45: Functional solid

Rectangle

+ draw()

GraphicalApplication

Computational Geometry Application

GUI

GeometricRectangle

+ area() : double

Page 46: Functional solid

Metaresponsibilities of an OO class...

• Model state

• Model behavior

Page 47: Functional solid

State

• car.color = black• elevator.floor = 10• account.balance = 2500

Page 48: Functional solid

Behavior

• car.drive()• elevator.climb()• account.deposit(500)

Page 49: Functional solid

How many metaresponsibilities?

Page 50: Functional solid

It is better to have 100 functions operate on one data structure than to have 10 functions operate

on 10 data structures.

Alan J. Perlis

Page 51: Functional solid
Page 52: Functional solid
Page 53: Functional solid

Metaresponsibilities of an OO class...

• Model state

• Model behavior

• Model identity

Page 54: Functional solid
Page 55: Functional solid

IDENTITY

VALUE

car1 != car2

car1 == car2

Page 56: Functional solid

Concurrent System

• Automated “Needs Service” Notification System

• Thread 1: Update mileage and “ready for service indicators”

• Thread 2: Harvest cars ready for service and send notifications

Page 57: Functional solid
Page 58: Functional solid
Page 59: Functional solid
Page 60: Functional solid

The Open Closed Principle

Page 61: Functional solid

Bertrand Myer

Page 62: Functional solid

Software entities should be open for extension but closed for modification.

Page 63: Functional solid

Open for extension...

Page 64: Functional solid

...closed for modification.

Page 65: Functional solid

Abstraction!

• Java:

• interface

• abstract class

Page 66: Functional solid
Page 67: Functional solid
Page 68: Functional solid
Page 69: Functional solid

(pause OCP)

Page 70: Functional solid

Let’s do design!

• OO language (Java)

• We want to use the OCP

• We’ll create one or more inheritance hierarchies!

• Well...

Page 71: Functional solid

Inheritance Hierarchies?

• What do good ones look like?

• Are there rules we can follow (best practices even)?

• Are there traps we can fall in to?

Page 72: Functional solid

Barbara Liskov

The Liskov Substitution Principle

Page 73: Functional solid

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.

Page 74: Functional solid

Subtypes must be substitutable for their

base types.

Page 75: Functional solid

f(B b) { }

Page 76: Functional solid

D extends B

Page 77: Functional solid

B d = new D();f(d)

Page 78: Functional solid

f(B b) { if (b instance of D) { //deal with D } else { //continue as before }}

Page 79: Functional solid

(resume OCP)

Page 80: Functional solid

CompositionThe Functional OCP

Page 81: Functional solid
Page 82: Functional solid
Page 83: Functional solid
Page 84: Functional solid
Page 85: Functional solid
Page 86: Functional solid

First-class Functions

Page 87: Functional solid
Page 88: Functional solid

Higher-order Functions

Page 89: Functional solid
Page 90: Functional solid

The Interface Segregation Principle

Page 91: Functional solid

Clients should not be forced to depend on

methods they do not use.

Page 92: Functional solid
Page 93: Functional solid
Page 94: Functional solid

<<interface>>TimerClient

+ timeout()Timer

0..*

Door

TimedDoor

Page 95: Functional solid
Page 96: Functional solid

<<interface>>TimerClient

+ timeout()Timer

0..*Door

DoorTimerAdapter

+ timeout()

<<creates>>

TimedDoor

+ doorTimeOut()

Page 97: Functional solid
Page 98: Functional solid

<<interface>>TimerClient

+ timeout()Timer Door

TimedDoor

+ timeout()

Page 99: Functional solid
Page 100: Functional solid
Page 101: Functional solid

Thinking in Verbs

Page 102: Functional solid

Verbs

• Open

• Close

• Register Timeout

• Trigger Timeout

Page 103: Functional solid
Page 104: Functional solid
Page 105: Functional solid

OK...what about that unique ID problem?

Page 106: Functional solid
Page 107: Functional solid
Page 108: Functional solid
Page 109: Functional solid

The Dependency Inversion Principle

Page 110: Functional solid

Abstractions should not depend upon details. Details

should depend upon abstractions.

Page 111: Functional solid

High-level modules should not depend on

low-level modules.

Page 112: Functional solid

Policy Layer

Mechanism Layer

Utility Layer

Page 113: Functional solid
Page 114: Functional solid

Policy Layer

Mechanism Layer

Utility Layer

<<interface>>Policy Service

Interface

<<interface>>Mechanism

Service Interface

Page 115: Functional solid
Page 116: Functional solid
Page 117: Functional solid
Page 118: Functional solid

Our verbs have been taken captive by

nouns...

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

Page 119: Functional solid
Page 120: Functional solid
Page 121: Functional solid

http://www.infoq.com/presentations/Simple-Made-Easy/

Page 122: Functional solid
Page 123: Functional solid
Page 124: Functional solid

Complectedness

Page 125: Functional solid

SRP

Complecting responsibilities leads to rigid and/or fragile design.

Page 126: Functional solid

OCP

Problematic:Complecting concretions of an

abstraction in such a way that new concretions adversely affect

existing, working concretions.

Page 127: Functional solid

LSP

Reuse via inheritance is dangerous. Often complects entities not in a true “is-a” relationship. Leads to non-

substitutability.

Page 128: Functional solid

ISP

Don’t complect unrelated operations in a single entity!

Page 129: Functional solid

DIP

Transitive dependency leads to transitive complectedness!

Page 130: Functional solid

Design is the art of breaking things apart.

- Rich Hickey

Page 131: Functional solid

Please fill out your evaluations!

Matt [email protected]

Twitter: mstinehttp://www.mattstine.com