This document provides biographical information about the speaker Matt Stine and outlines the topics he will cover in his presentation. Stine will discuss how software designs tend to degrade over time due to various factors, and how following the SOLID principles of object-oriented design can help address this problem and make designs more functional in nature. He will also cover trends in how software systems evolve, different programming paradigms, and the ongoing quest for software design "best practices."

1. Functional Soλid
Matt Stine

2. About your speaker...
• Senior Consultant, PSO
vFabric, Cloud Application Platform
VMware
• 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

3. SOLID Functional
Principles Programming

4. SOLID Functional
PrinciplesProgramming

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

6. Motivation

8. Trends
• How Software Systems Evolve
• Programming Paradigms
• The Quest for “Best Practices”

9. The evolution of
software...

10. http://www.flickr.com/photos/billselak/427719926
http://www.flickr.com/photos/unloveable/2400895854
From simplicity to complexity...

11. http://www.flickr.com/photos/thejcgerm/379082415
Software starts
to rot like a
bad piece of
meat.
“Uncle Bob”
Martin

12. We don’t handle
change well...

13. Unclear or incomplete
change specifications...

14. Extreme time
pressure...

15. Team members
unfamiliar with original
design/architecture...

16. It smells!

17. Rigidity

18. Fragility

19. Immobility

20. Viscosity

21. Needless Complexity

22. Needless Repetition

23. Opacity

24. Programming
Paradigms

25. Programming eras...
• Structured Programming
(late 1960’s - late 1980’s)
• Object Oriented Programming
(mid 1970’s - present day)
• Functional Programming
(early 1990’s - ???)

27. THE CHASM

29. Accumulation of
Knowledge?

30. Accumulation of
Knowledge?

31. Paradigm Shifts

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

33. The Quest
for
“Best Practices”

34. • 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?

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

36. What are the FP best
practices?

37. The Perfect Storm

38. SRP OCP LSP
The
SOLID
ISP DIP Principles

39. http://clojure.org

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

41. The Single
Responsibility Principle

42. A class (module) should
have only one reason
to change.

43. COHESION
Tom DeMarco Meilir Page-Jones

44. Computational Rectangle
Graphical
Geometry + draw() Application
Application + area() : double
GUI

45. Computational
Graphical
Geometry
Application
Application
Geometric Rectangle
Rectangle
GUI
+ draw()
+ area() : double

46. Metaresponsibilities of
an OO class...
• Model state
• Model behavior

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

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

49. How many
metaresponsibilities?

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

53. Metaresponsibilities of
an OO class...
• Model state
• Model behavior
• Model identity

55. IDENTITY
car1 != car2
VALUE
car1 == car2

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

60. The Open Closed
Principle

61. Bertrand Myer

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

63. Open for extension...

64. ...closed for
modification.

65. Abstraction!
• Java:
• interface
• abstract class

69. (pause OCP)

70. Let’s do design!
• OO language (Java)
• We want to use the OCP
• We’ll create one or more inheritance
hierarchies!
• Well...

71. 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?

72. The Liskov
Substitution Principle
Barbara Liskov

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

74. Subtypes must be
substitutable for their
base types.

75. f(B b) { }

76. D extends B

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

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

79. (resume OCP)

80. Composition
The Functional OCP

86. First-class Functions

88. Higher-order Functions

90. The Interface
Segregation Principle

91. Clients should not be
forced to depend on
methods they do not use.

94. <<interface>>
TimerClient
Timer
0..*
+ timeout()
Door
TimedDoor

96. <<interface>>
TimerClient
Timer Door
0..*
+ timeout()
DoorTimerAdapter TimedDoor
+ timeout() + doorTimeOut()
<<creates>>

98. <<interface>>
TimerClient
Timer Door
+ timeout()
TimedDoor
+ timeout()

101. Thinking in Verbs

102. Verbs
• Open
• Close
• Register Timeout
• Trigger Timeout

105. OK...what about that
unique ID problem?

109. The Dependency
Inversion Principle

110. Abstractions should not
depend upon details. Details
should depend upon
abstractions.

111. High-level modules
should not depend on
low-level modules.

112. Policy Layer
Mechanism
Layer
Utility Layer

114. <<interface>>
Policy Layer Policy Service
Interface
<<interface>>
Mechanism
Mechanism
Layer
Service Interface
Utility Layer

118. Our verbs have been
taken captive by
nouns...
http://steve-yegge.blogspot.com/2006/03/execution-in-
kingdom-of-nouns.html

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

124. Complectedness

125. SRP
Complecting responsibilities leads
to rigid and/or fragile design.

126. OCP
Problematic:
Complecting concretions of an
abstraction in such a way that new
concretions adversely affect
existing, working concretions.

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

128. ISP
Don’t complect unrelated
operations in a single entity!

129. DIP
Transitive dependency leads to
transitive complectedness!

130. Design is the art of breaking
things apart.
- Rich Hickey

131. Matt Stine
matt.stine@gmail.com
Twitter: mstine
http://www.mattstine.com
Please fill out your evaluations!