Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
1 of 131

More Related Content

You Might Also Like

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

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 Functional Principles Programming
  4. 4. SOLID Functional PrinciplesProgramming
  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 incomplete change specifications...
  13. 13. Extreme time pressure...
  14. 14. Team members unfamiliar 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 SOLID ISP DIP Principles
  36. 36. http://clojure.org
  37. 37. http://www.infoq.com/presentations/SOLID-Clojure
  38. 38. The Single Responsibility Principle
  39. 39. A class (module) should have only one reason to change.
  40. 40. COHESION Tom 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 many metaresponsibilities?
  47. 47. 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
  48. 48. Metaresponsibilities of an OO class... • Model state • Model behavior • Model identity
  49. 49. IDENTITY car1 != car2 VALUE car1 == 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 should be open for extension but closed for modification.
  54. 54. Open for extension...
  55. 55. ...closed for modification.
  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 Principle Barbara Liskov
  61. 61. 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.
  62. 62. Subtypes must be substitutable 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 Interface Segregation Principle
  72. 72. Clients should not be forced to depend on methods they do not use.
  73. 73. <<interface>> TimerClient Timer 0..* + timeout() Door TimedDoor
  74. 74. <<interface>> TimerClient Timer Door 0..* + timeout() DoorTimerAdapter TimedDoor + timeout() + doorTimeOut() <<creates>>
  75. 75. <<interface>> TimerClient Timer Door + timeout() TimedDoor + timeout()
  76. 76. Thinking in Verbs
  77. 77. Verbs • Open • Close • Register Timeout • Trigger Timeout
  78. 78. OK...what about that unique ID problem?
  79. 79. The Dependency Inversion Principle
  80. 80. Abstractions should not depend upon details. Details should depend upon abstractions.
  81. 81. High-level modules should 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. SRP Complecting responsibilities leads to rigid and/or fragile design.
  88. 88. OCP Problematic: Complecting concretions of an abstraction in such a way that new concretions adversely affect existing, working concretions.
  89. 89. LSP Reuse via inheritance is dangerous. Often complects entities not in a true “is-a” relationship. Leads to non- substitutability.
  90. 90. ISP Don’t complect unrelated operations in a single entity!
  91. 91. DIP Transitive 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.com Please fill out your evaluations!

×