Bringing OOP Best Practices to the World of Functional Programming Elana Hashman Rackspace Managed Security Lambda Ladies DC – October 20!" #ehashdn DESIGN PATTERNS $unctional programming% Ob&ect-oriented programming% Programming Paradigms What is O !ect-Oriented Programming #OOP$% – (rogram logic is organized around objects, +hich store data as properties and algorithms ,or the data as methods – Objects are described by classes, +hich can inherit from one another – Common recipes/best practices are codified as design patterns Examples – C/+, 0a1a, C#, (ython Programming Paradigms What is Functional Programming (FP$% – Logic is codified and e1aluated as pure functions* a1oiding the mutation of state – Commonly characteri)ed by the use o, first-order functions* which can be passed around as arguments* and higher-order functions* which take functions as arguments E.amples – Lisp 3with 1arious dialects* such as Clo&ure4* Haskell, OCaml, $2 The fateful interview (Programming Tropes* + a.k.a. DESIGN PATTERNS 5hat is 6good code%7 68 can't tell you what bad code looks like, but I know it when I see it:7 " Anon.mous Programmer Don't Repeat Yourself (DR;4 Ya Ain't Gonna Need It 3;<=>84 eep It Simple, Senator 3?8SS4 (defn common-logic [data case-specific-logic] (case-specific-logic data) ...) (defn data1-specific-logic [args] ...) (defn data2-specific-logic [args] ...) (for [[data fn] data-and-fns] (common-logic data fn)) I. Di,,erent programming paradigms are not as di,,erent as you might think. II, Di,,erent programming paradigms do ha1e di,,erent design philosophies. 68t is better to ha1e ! functions operate on one data structure than 10 ,unctions on 10 data structures.7 " Alan /. Perlis III. >o paradigm is ob&ecti1ely 6better*” but each has ad1antages in certain situations: A common critique o, the 6Gang o, $our” !AAB Design Patterns book +as that many o, the patterns ser1ed as +orkarounds ,or language limitations o, C++. 8n !AAC, Peter >or1ig claims that !C o, the 23 patterns in the Gang of $our book are invisible or simplified in Lisp! <bstract $actory* Fly+eight* Factory Method* State* (roxy* Chain o, Responsibility → first"class t.)es Command* Strategy* Femplate* Visitor → first-class functions 8nterpreter* Iterator → macros Mediator* Observer → method combination Huilder → multimethods $açade → modules $unctional programming language ,eatures can reduce the need to use ,ully-implemented class-based design patterns. Some Notable FP 0anguage Features Immutabilit. What is it% – Data cannot change state a,ter its creation – $unctions cannot ha1e 6side e,,ects7 8mpro1es ability to reason about code Simpli,ies unit testing Discourages the use o, global mutable state, i.e. Singleton pattern First-1lass Functions What are the.% – $unctions can be passed as arguments – Lexical scoping allo+s ,or local bindings o, 1alues $urr%ing gi1es us ,unction $actories ((fn [a] (fn [b] (does-stuff a b))) “yo”) => (fn [b] (does-stuff “yo” b)) ; a := “yo” Freating ,unctions like +e treat data gi1es us programmable po+er o1er them 2acros and Pattern 2atching What are the.% – MacrosJ +e can write code to generate code – (attern Matching: match data according to patterns! Enables writing new grammar and e1aluating it +ith ease* i.e. Interpreter pattern Hre1ity means de1s can write more with less time, and the resulting code needs less maintenance (attern match e.ample.:: 2acros and Pattern 2atching (defn message-origin [message] (matc" [message] [#!parsed #!metadata #!customer-id-string $%%%] !type1 [#!parsed #!id $ !type $ !critical $ !message $%%] !type2 [#!parsed $%] !&son !else !syslog)) Some Examples of Design Patterns The Façade and Adapter Patterns What are the.% – Hide an e.isting A(8 by providing a new one on top The Façade and Adapter Patterns When to use them% – (ro1ide a unified or simplified inter,ace ,or other code – &echnical debt wrangling' standardize an inter,ace so you can re,actor the original code behind it When not to use them% – Foo many layers o, indirection from the original <PI can be ,ragile 5o' to use them with FP% – 0ust like you +ould in the OOP +orldE – 5rite modules +ith public ,unctions instead o, classes (defn yucky-API [hot dog other-infos] ...) (defn consumes-yucky-A)I [] (yucky-API true true #!"ot true :dog true :sundaes “???”%)) (defn nice-API “helpful docstring!” [other-infos] (let [{:keys [hot dog]} other-infos] (yuc'y-()* hot dog other-infos))) The Template Pattern What is it% – Defines the ma&ority o, an algorithm in an operation* de,erring some steps to subclasses The Template Pattern When to use it% – >early identical data and data operations – >eed to stub out a small amount of ,unctionality When not to use it% – Kse abstract base classes or similar very sparingly – 8n OOP land: pre,er composition o1er inheritance 5o' to use it with FP? – (ass in stub functions as arguments to common logic instead of implementing stubs on subclasses (defn common-logic [data case-specific-logic] (case-specific-logic data) ...) (defn data1-specific-logic [args] ...) (defn data2-specific-logic [args] ...) (for [[data fn] data-and-fns] (common-logic data fn)) The Strategy Pattern What is it% – Conditionally switch algorithms in a gi1en conte.t The Strategy Pattern When to use it% – Encapsulates dispatching many variants of a similar algorithm – $eature'flagged functionality When not to use it% – 5hen strategies fundamentally di,,er 3e:g: return type4 – <dds comple.ity and code branching 5o' to use it with FP? – (ass in algorithm 1ariants as first-order functions (defn strategy1 [args] ...) (defn strategy2 [args] ...) (apply-strategy-a [strategy1 strategy2]) (apply-strategy-b (fn [cond] (if cond strategy1 strategy2)) Summary 5e co1ered some Structural design patterns from – <dapter all three categoriesE – $aIade 1reational Beha&ioural – $actory – 8nterpreter – Singleton – Strategy – Femplate 1on!ecture: ;ou can use functional programming languages to write enterprise soft+are: Next time: Monads L Design patterns ,or statically typed languages% Thank you7 Fhanks to: Nik Black* Fatema Bo.+ala, Shane Wilton, Red Hat &alk links" references" and resources can be found at httpsJ--hashman.ca/osb'20!C- #ehashdn Talk References Erich Gamma* Richard Helm, Ralph Johnson, and 0ohn Vlissides* Design Patterns: Elements of Reusable Object-Oriented Software 3!AAB4 – Re,erred to as the “Gang o, Four7 (eter Norvig* “Design Patterns in Dynamic Languages7 (!AAC4 Image Licenses Pu lic Domain – Meta-KML Diagram – <dapter (attern KML Diagram – Strategy (attern KML Diagram 1reati&e 1ommons Share Alike 8,9 :n)orted 0icense – KML diagram of composition o1er inheritance – Femplate Method: KML Class Diagram – $acade Design (attern in KML .