Bringing OOP Best Practices to the World of Functional Programming
Total Page：16
File Type：pdf, Size：1020Kb
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 .