Functional Soλid     Matt Stine
About your speaker...•   Senior Consultant, PSO    vFabric, Cloud Application Platform    VMware•   Speaker (JavaOne, Spri...
SOLID        FunctionalPrinciples   Programming
SOLID FunctionalPrinciplesProgramming
Pitch• Software designs tend to rot.• Design rot impedes our effectiveness.• SOLID principles help treat design rot.• Achi...
Motivation
Trends• How Software Systems Evolve• Programming Paradigms• The Quest for “Best Practices”
The evolution of  software...
http://www.flickr.com/photos/billselak/427719926                                                  http://www.flickr.com/phot...
http://www.flickr.com/photos/thejcgerm/379082415                                                  Software starts          ...
We don’t handle change well...
Unclear or incompletechange specifications...
Extreme time pressure...
Team membersunfamiliar with original design/architecture...
It smells!
Rigidity
Fragility
Immobility
Viscosity
Needless Complexity
Needless Repetition
Opacity
Programming Paradigms
Programming eras...• Structured Programming  (late 1960’s - late 1980’s)• Object Oriented Programming  (mid 1970’s - prese...
THE CHASM
Accumulation of Knowledge?
Accumulation of Knowledge?
Paradigm Shifts
http://www.gotw.ca/publications/concurrency-ddj.htm
The Quest      for“Best Practices”
• Which web framework should I use?• Why are there so many persistence API’s?• Which is better: Scala or Clojure (or  Erla...
http://en.wikipedia.org/wiki/No_Silver_Bullet
What are the FP best    practices?
The Perfect Storm
SRP   OCP        LSP             The           SOLIDISP   DIP Principles
http://clojure.org
http://www.infoq.com/presentations/SOLID-Clojure
The SingleResponsibility Principle
A class (module) should have only one reason       to change.
COHESIONTom DeMarco   Meilir Page-Jones
Computational      Rectangle                                     Graphical Geometry       + draw()            Application ...
Computational                       Graphical  Geometry                      Application  Application   Geometric         ...
Metaresponsibilities of   an OO class...• Model state• Model behavior
State•   car.color = black•   elevator.floor = 10•   account.balance = 2500
Behavior•   car.drive()•   elevator.climb()•   account.deposit(500)
How manymetaresponsibilities?
It is better to have 100 functions operate on onedata structure than to have 10 functions operate               on 10 data...
Metaresponsibilities of   an OO class...• Model state• Model behavior• Model identity
IDENTITYcar1 != car2   VALUEcar1 == car2
Concurrent System• Automated “Needs Service” Notification  System• Thread 1: Update mileage and “ready for  service indicat...
The Open Closed    Principle
Bertrand Myer
Software entities shouldbe open for extension but closed for modification.
Open for extension...
...closed formodification.
Abstraction!• Java: • interface • abstract class
(pause OCP)
Let’s do design!• OO language (Java)• We want to use the OCP• We’ll create one or more inheritance  hierarchies!• Well...
Inheritance          Hierarchies?• What do good ones look like?• Are there rules we can follow (best  practices even)?• Ar...
The Liskov                 Substitution PrincipleBarbara Liskov
What is wanted here is something like the followingsubstitution property: If for each object o1 of type S there is an obje...
Subtypes must besubstitutable for their     base types.
f(B b) { }
D extends B
B d = new D();     f(d)
f(B b) {	 if (b instance of D) {	 	 //deal with D	 } else {	 	 //continue as before	}}
(resume OCP)
Composition The Functional OCP
First-class Functions
Higher-order Functions
The InterfaceSegregation Principle
Clients should not be  forced to depend onmethods they do not use.
<<interface>>                  TimerClientTimer        0..*               + timeout()                     Door            ...
<<interface>>                  TimerClientTimer                                               Door        0..*            ...
<<interface>>           TimerClientTimer                                    Door        + timeout()                       ...
Thinking in Verbs
Verbs• Open• Close• Register Timeout• Trigger Timeout
OK...what about thatunique ID problem?
The DependencyInversion Principle
Abstractions should notdepend upon details. Details   should depend upon       abstractions.
High-level modulesshould not depend on  low-level modules.
Policy Layer               Mechanism                 Layer                           Utility Layer
<<interface>>Policy Layer   Policy Service                 Interface                                 <<interface>>        ...
Our verbs have been       taken captive by            nouns...http://steve-yegge.blogspot.com/2006/03/execution-in-       ...
http://www.infoq.com/presentations/Simple-Made-Easy/
Complectedness
SRPComplecting responsibilities leads  to rigid and/or fragile design.
OCP            Problematic:  Complecting concretions of anabstraction in such a way that new   concretions adversely affec...
LSP  Reuse via inheritance isdangerous. Often complects entities not in a true “is-a” relationship. Leads to non-        s...
ISP Don’t complect unrelatedoperations in a single entity!
DIPTransitive dependency leads to  transitive complectedness!
Design is the art of breaking        things apart.       - Rich Hickey
Matt Stine         matt.stine@gmail.com             Twitter: mstine       http://www.mattstine.comPlease fill out your eval...
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Functional solid
Upcoming SlideShare
Loading in...5
×

Functional solid

1,383

Published on

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

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,383
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
34
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Functional solid

  1. 1. Functional Soλid Matt Stine
  2. 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. 3. SOLID FunctionalPrinciples Programming
  4. 4. SOLID FunctionalPrinciplesProgramming
  5. 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. 6. Motivation
  7. 7. Trends• How Software Systems Evolve• Programming Paradigms• The Quest for “Best Practices”
  8. 8. The evolution of software...
  9. 9. http://www.flickr.com/photos/billselak/427719926 http://www.flickr.com/photos/unloveable/2400895854 From simplicity to complexity...
  10. 10. http://www.flickr.com/photos/thejcgerm/379082415 Software starts to rot like a bad piece of meat. “Uncle Bob” Martin
  11. 11. We don’t handle change well...
  12. 12. Unclear or incompletechange specifications...
  13. 13. Extreme time pressure...
  14. 14. Team membersunfamiliar with original design/architecture...
  15. 15. It smells!
  16. 16. Rigidity
  17. 17. Fragility
  18. 18. Immobility
  19. 19. Viscosity
  20. 20. Needless Complexity
  21. 21. Needless Repetition
  22. 22. Opacity
  23. 23. Programming Paradigms
  24. 24. Programming eras...• Structured Programming (late 1960’s - late 1980’s)• Object Oriented Programming (mid 1970’s - present day)• Functional Programming (early 1990’s - ???)
  25. 25. THE CHASM
  26. 26. Accumulation of Knowledge?
  27. 27. Accumulation of Knowledge?
  28. 28. Paradigm Shifts
  29. 29. http://www.gotw.ca/publications/concurrency-ddj.htm
  30. 30. The Quest for“Best Practices”
  31. 31. • 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?
  32. 32. http://en.wikipedia.org/wiki/No_Silver_Bullet
  33. 33. What are the FP best practices?
  34. 34. The Perfect Storm
  35. 35. SRP OCP LSP The SOLIDISP DIP Principles
  36. 36. http://clojure.org
  37. 37. http://www.infoq.com/presentations/SOLID-Clojure
  38. 38. The SingleResponsibility Principle
  39. 39. A class (module) should have only one reason to change.
  40. 40. COHESIONTom DeMarco Meilir Page-Jones
  41. 41. Computational Rectangle Graphical Geometry + draw() Application Application + area() : double GUI
  42. 42. Computational Graphical Geometry Application Application Geometric Rectangle Rectangle GUI + draw()+ area() : double
  43. 43. Metaresponsibilities of an OO class...• Model state• Model behavior
  44. 44. State• car.color = black• elevator.floor = 10• account.balance = 2500
  45. 45. Behavior• car.drive()• elevator.climb()• account.deposit(500)
  46. 46. How manymetaresponsibilities?
  47. 47. It is better to have 100 functions operate on onedata structure than to have 10 functions operate on 10 data structures. Alan J. Perlis
  48. 48. Metaresponsibilities of an OO class...• Model state• Model behavior• Model identity
  49. 49. IDENTITYcar1 != car2 VALUEcar1 == car2
  50. 50. 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
  51. 51. The Open Closed Principle
  52. 52. Bertrand Myer
  53. 53. Software entities shouldbe open for extension but closed for modification.
  54. 54. Open for extension...
  55. 55. ...closed formodification.
  56. 56. Abstraction!• Java: • interface • abstract class
  57. 57. (pause OCP)
  58. 58. Let’s do design!• OO language (Java)• We want to use the OCP• We’ll create one or more inheritance hierarchies!• Well...
  59. 59. 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?
  60. 60. The Liskov Substitution PrincipleBarbara Liskov
  61. 61. What is wanted here is something like the followingsubstitution 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.
  62. 62. Subtypes must besubstitutable for their base types.
  63. 63. f(B b) { }
  64. 64. D extends B
  65. 65. B d = new D(); f(d)
  66. 66. f(B b) { if (b instance of D) { //deal with D } else { //continue as before }}
  67. 67. (resume OCP)
  68. 68. Composition The Functional OCP
  69. 69. First-class Functions
  70. 70. Higher-order Functions
  71. 71. The InterfaceSegregation Principle
  72. 72. Clients should not be forced to depend onmethods they do not use.
  73. 73. <<interface>> TimerClientTimer 0..* + timeout() Door TimedDoor
  74. 74. <<interface>> TimerClientTimer Door 0..* + timeout() DoorTimerAdapter TimedDoor + timeout() + doorTimeOut() <<creates>>
  75. 75. <<interface>> TimerClientTimer Door + timeout() TimedDoor + timeout()
  76. 76. Thinking in Verbs
  77. 77. Verbs• Open• Close• Register Timeout• Trigger Timeout
  78. 78. OK...what about thatunique ID problem?
  79. 79. The DependencyInversion Principle
  80. 80. Abstractions should notdepend upon details. Details should depend upon abstractions.
  81. 81. High-level modulesshould not depend on low-level modules.
  82. 82. Policy Layer Mechanism Layer Utility Layer
  83. 83. <<interface>>Policy Layer Policy Service Interface <<interface>> Mechanism Mechanism Layer Service Interface Utility Layer
  84. 84. Our verbs have been taken captive by nouns...http://steve-yegge.blogspot.com/2006/03/execution-in- kingdom-of-nouns.html
  85. 85. http://www.infoq.com/presentations/Simple-Made-Easy/
  86. 86. Complectedness
  87. 87. SRPComplecting responsibilities leads to rigid and/or fragile design.
  88. 88. OCP Problematic: Complecting concretions of anabstraction in such a way that new concretions adversely affect existing, working concretions.
  89. 89. LSP Reuse via inheritance isdangerous. Often complects entities not in a true “is-a” relationship. Leads to non- substitutability.
  90. 90. ISP Don’t complect unrelatedoperations in a single entity!
  91. 91. DIPTransitive dependency leads to transitive complectedness!
  92. 92. Design is the art of breaking things apart. - Rich Hickey
  93. 93. Matt Stine matt.stine@gmail.com Twitter: mstine http://www.mattstine.comPlease fill out your evaluations!
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×