Functional Programming: a Pragpub Anthology

Total Page:16

File Type:pdf, Size:1020Kb

Functional Programming: a Pragpub Anthology Prepared exclusively for Shohei Tanaka Prepared exclusively for Shohei Tanaka Early Praise for Functional Programming: A PragPub Anthology If you’ve been wondering what all the functional hubbub is about, Functional Programming: A PragPub Anthology will satisfy. You can wet your whistle with several languages, get a feel for how to think functionally, and do so without overcommitting to one language or school of thought. ➤ Ben Vandgrift Chief architect, Oryx Systems Inc. Programming’s last sea change was in the 1990s when object orientation went mainstream. It’s happening again, but this time it’s functional programming that’s sweeping through our profession. Read this book to understand why and to learn how to ride the wave. ➤ Paul Butcher Founder and CTO, writeandimprove.com I really enjoyed the structure and flow of the book. The chapters stand on their own as essays but when put together make a strong argument for functional programming, regardless of the language. It’s also a treat to see all these different familiar writers write about diverse languages. ➤ Ben Marx Lead engineer, Bleacher Report Prepared exclusively for Shohei Tanaka You’re sure to find a way functional programming resonates with you with the wealth of approaches and languages covered. The treatment of Scala collection is superb: everything a beginner needs to know from the get-go! ➤ Jeff Heon Research software developer, CRIM Prepared exclusively for Shohei Tanaka Functional Programming: A PragPub Anthology Exploring Clojure, Elixir, Haskell, Scala, and Swift Michael Swaine and the PragPub writers The Pragmatic Bookshelf Raleigh, North Carolina Prepared exclusively for Shohei Tanaka Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and The Pragmatic Programmers, LLC was aware of a trademark claim, the designations have been printed in initial capital letters or in all capitals. The Pragmatic Starter Kit, The Pragmatic Programmer, Pragmatic Programming, Pragmatic Bookshelf, PragProg and the linking g device are trade- marks of The Pragmatic Programmers, LLC. Every precaution was taken in the preparation of this book. However, the publisher assumes no responsibility for errors or omissions, or for damages that may result from the use of information (including program listings) contained herein. Our Pragmatic books, screencasts, and audio books can help you and your team create better software and have more fun. Visit us at https://pragprog.com. The team that produced this book includes: Publisher: Andy Hunt VP of Operations: Janet Furlow Executive Editor: Susannah Davidson Pfalzer Indexing: Potomac Indexing, LLC Copy Editor: Nicole Abramowitz Layout: Gilson Graphics For sales, volume licensing, and support, please contact [email protected]. For international rights, please contact [email protected]. Copyright © 2017 The Pragmatic Programmers, LLC. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher. Printed in the United States of America. ISBN-13: 978-1-68050-233-6 Encoded using the finest acid-free high-entropy binary digits. Book version: P1.0—July 2017 Prepared exclusively for Shohei Tanaka Contents Introduction . xi Acknowledgements . xiii Part I — The Functional Paradigm 1. Functional Programming Is Big Again . 3 We’ve Seen This Movie Before 3 New Arguments for Functional Programming 5 2. Functional Thinking for the Imperative Mind . 7 It’s About Functions 7 It’s About Immutability 8 It’s a Way of Thinking 9 Part II — Scala: A Hybrid Language 3. Scala and Functional Style . 15 Functional Purity 15 Higher-Order Functions 15 A Simple Example 16 A Practical Example 18 What About Debugging and Performance? 21 4. Working with Scala Collections . 23 Immutable Collections 23 Mutable Collections 27 Lazy Collections 27 Prepared exclusively for Shohei Tanaka Contents • vi 5. Creating Higher-Order Functions in Scala . 31 Creating a Higher-Order Function 31 Multiple Parameter Lists 34 Function Values and the Loan Pattern 35 Part III — Clojure: The New Lisp 6. An Interview with Rich Hickey . 41 Why Clojure? 41 The Infrastructure 42 Compared to What? 43 7. Getting Clojure: Why Lisp Still Matters . 45 The REPL 45 Vectors and Keywords 47 Macros 49 8. Identity, Value, and State in Clojure . 51 The Object-Oriented Model 51 The Clojure Model 54 9. Concurrent Programming in Clojure . 59 A "Simple" Concurrent Programming Problem 59 Clojure’s Solution 61 Part IV — Elixir: Making Programming Fun Again 10. Patterns and Transformations in Elixir . 69 Pattern Matching 70 Pattern Matching Structured Data 71 Pattern Matching and Functions 72 Transformation Is Job #1 73 11. Getting Functional with Elixir . 75 Anonymous Functions 75 Named Functions 76 A Practical Example 78 Refactor to Functional Style 80 What’s Different About This Code 83 12. Getting Parallel with Elixir . 85 The Actor Model 85 Prepared exclusively for Shohei Tanaka Contents • vii Actors and Elixir 86 Messages 87 Monitoring Your Processes 91 A Final Example 92 Concurrency Is the Core of Elixir 94 Part V — Haskell: The Researcher’s Playground 13. Functional Thinking and Haskell . 97 What It’s All About 97 A Quick Exercise 98 Data Types Are Cheap 99 Pattern Matching 102 Recursion, Control, and Higher-Order Functions 103 Further Features 105 14. Haskell Hands-On . 109 One Step at a Time 110 Generating Candidates 113 Dictionary Filtering 116 Breadth-First Searching 117 Using the Search 120 Performance and Optimization 121 Part VI — Swift: Functional Programming for Mobile Apps 15. Swift: What You Need to Know . 125 Hello, Swift! 126 Functional Swift 127 16. Functional Thinking in Swift . 133 Avoid Nil, Unless You Mean It 133 Avoid Mutable State 135 Use Higher-Order Functions 136 Prepared exclusively for Shohei Tanaka Contents • viii Part VII — Going Deeper 17. Protocols in Swift vs. Ruby and Elixir . 143 The Problem with Extensions 144 The Case for Protocols 145 Protocols and Extensions 147 18. Pattern Matching in Scala . 149 Counting Coins 149 Matching All the Things 152 Using Extractions 153 19. Concurrency in Scala . 157 Using Parallel Collections 157 Knowing When to Use Concurrency 159 Revisiting an Earlier Example 161 20. Clojure’s Exceptional Handling of Exceptions . 163 A Simple Example 164 The Problem with Exceptions 165 A Solution: Conditions 165 Make Life Simple for Your Callers 166 Laziness and Errors 167 21. A Testing Framework for Elixir . 169 Investing in Testing 169 One Experiment, Several Measurements 170 Optimizing Setup with TrueStory 171 Condense and Combine the Measurements 172 Controlling Setup Repetition with Nested Contexts 173 Controlling Setup Repetition with Story Pipes 174 22. Building Test Data with Elixir . 177 The Typical Approaches 177 Beautiful Data for Beautiful Tests 178 Registering Templates and Prototypes with Forge 179 Instantiating Template Entries 180 Mutual Attributes and Having 180 Creating Structs 181 Creating Custom Entities 181 Customizing Persistence 182 Prepared exclusively for Shohei Tanaka Contents • ix 23. Haskell’s Type System . 185 TL;DR 185 What Are Types For? 186 A Concrete Example: Sorting 187 The Language of Haskell’s Type System 189 Type Inference and Type Checking 190 Some Examples 191 Comfort Break 194 Interfaces and Type Classes 195 Some Real-World Examples with Interfaces 200 Pros and Cons—the 80/20 Rule 202 Beyond Haskell: Dependent Types 203 Propositions Are Types, and Proofs Are Programs 204 Another Look at Sorting 205 Back to Earth 207 24. A Haskell Project: Testing Native Code . 211 Our Native Code 212 Our Model 212 A Brief Introduction to Haskell’s FFI 213 Wrapping Our Native Code in Haskell 213 Experimenting with GHCi 214 A Brief Introduction to QuickCheck 215 Writing an Equivalence Property 215 Defect Smashing 218 25. The Many Faces of Swift Functions . 221 Anatomy of Swift Functions 222 Calling All Functions 222 Calling on Methods 223 Instance Methods Are Curried Functions 224 Init: A Special Note 225 Fancy Parameters 227 Access Controls 233 Fancy Return Types 234 Nested Functions 237 26. A Functional Approach to Lua . 239 First-Class Functions in Lua 239 Recursion in Lua 241 Prepared exclusively for Shohei Tanaka Contents • x Building with Functional Primitives 242 A Simple Game Animation 243 A1. Meet the Authors . 247 Bibliography . 251 Index . 253 Prepared exclusively for Shohei Tanaka Introduction by Michael Swaine This book shows how five different languages approach the paradigm of functional programming. The chapters were written by experts in the different languages and first appeared as articles in PragPub magazine. After publishing nearly one hundred issues of the magazine, it became clear that we were in possession of a wealth of information about functional programming, and we decided that some of the best articles would make an interesting book. Functional programming is one of the major paradigms of programming. In functional programming, we approach computation as the evaluation of mathematical functions, and as much as possible we avoid changing state and mutable data. Certain concepts and issues are sure to come up in any discussion of func- tional programming. Recursion. Lazy evaluation. Referential transparency. Eliminating side effects. Functions as first-class objects. Higher-level functions. Currying. Immutable data. Type systems. Pattern matching. The authors touch on all these concepts, looking at them from the perspective of different languages. But functional programming is not an all-or-none thing. It is perfectly reason- able to write imperative code that uses functional techniques and practices and data structures. It is fine to mix and match styles, and some programming languages are designed as hybrids, allowing you to use the style that best fits your needs of the moment. Scala, for example, or Mathematica, or Swift. Our authors explore these different approaches in this book, and you can decide which works best for you.
Recommended publications
  • Building Great Interfaces with OOABL
    Building great Interfaces with OOABL Mike Fechner Director Übersicht © 2018 Consultingwerk Ltd. All rights reserved. 2 Übersicht © 2018 Consultingwerk Ltd. All rights reserved. 3 Übersicht Consultingwerk Software Services Ltd. ▪ Independent IT consulting organization ▪ Focusing on OpenEdge and related technology ▪ Located in Cologne, Germany, subsidiaries in UK and Romania ▪ Customers in Europe, North America, Australia and South Africa ▪ Vendor of developer tools and consulting services ▪ Specialized in GUI for .NET, Angular, OO, Software Architecture, Application Integration ▪ Experts in OpenEdge Application Modernization © 2018 Consultingwerk Ltd. All rights reserved. 4 Übersicht Mike Fechner ▪ Director, Lead Modernization Architect and Product Manager of the SmartComponent Library and WinKit ▪ Specialized on object oriented design, software architecture, desktop user interfaces and web technologies ▪ 28 years of Progress experience (V5 … OE11) ▪ Active member of the OpenEdge community ▪ Frequent speaker at OpenEdge related conferences around the world © 2018 Consultingwerk Ltd. All rights reserved. 5 Übersicht Agenda ▪ Introduction ▪ Interface vs. Implementation ▪ Enums ▪ Value or Parameter Objects ▪ Fluent Interfaces ▪ Builders ▪ Strong Typed Dynamic Query Interfaces ▪ Factories ▪ Facades and Decorators © 2018 Consultingwerk Ltd. All rights reserved. 6 Übersicht Introduction ▪ Object oriented (ABL) programming is more than just a bunch of new syntax elements ▪ It’s easy to continue producing procedural spaghetti code in classes ▪
    [Show full text]
  • Functional Languages
    Functional Programming Languages (FPL) 1. Definitions................................................................... 2 2. Applications ................................................................ 2 3. Examples..................................................................... 3 4. FPL Characteristics:.................................................... 3 5. Lambda calculus (LC)................................................. 4 6. Functions in FPLs ....................................................... 7 7. Modern functional languages...................................... 9 8. Scheme overview...................................................... 11 8.1. Get your own Scheme from MIT...................... 11 8.2. General overview.............................................. 11 8.3. Data Typing ...................................................... 12 8.4. Comments ......................................................... 12 8.5. Recursion Instead of Iteration........................... 13 8.6. Evaluation ......................................................... 14 8.7. Storing and using Scheme code ........................ 14 8.8. Variables ........................................................... 15 8.9. Data types.......................................................... 16 8.10. Arithmetic functions ......................................... 17 8.11. Selection functions............................................ 18 8.12. Iteration............................................................. 23 8.13. Defining functions ...........................................
    [Show full text]
  • The Machine That Builds Itself: How the Strengths of Lisp Family
    Khomtchouk et al. OPINION NOTE The Machine that Builds Itself: How the Strengths of Lisp Family Languages Facilitate Building Complex and Flexible Bioinformatic Models Bohdan B. Khomtchouk1*, Edmund Weitz2 and Claes Wahlestedt1 *Correspondence: [email protected] Abstract 1Center for Therapeutic Innovation and Department of We address the need for expanding the presence of the Lisp family of Psychiatry and Behavioral programming languages in bioinformatics and computational biology research. Sciences, University of Miami Languages of this family, like Common Lisp, Scheme, or Clojure, facilitate the Miller School of Medicine, 1120 NW 14th ST, Miami, FL, USA creation of powerful and flexible software models that are required for complex 33136 and rapidly evolving domains like biology. We will point out several important key Full list of author information is features that distinguish languages of the Lisp family from other programming available at the end of the article languages and we will explain how these features can aid researchers in becoming more productive and creating better code. We will also show how these features make these languages ideal tools for artificial intelligence and machine learning applications. We will specifically stress the advantages of domain-specific languages (DSL): languages which are specialized to a particular area and thus not only facilitate easier research problem formulation, but also aid in the establishment of standards and best programming practices as applied to the specific research field at hand. DSLs are particularly easy to build in Common Lisp, the most comprehensive Lisp dialect, which is commonly referred to as the “programmable programming language.” We are convinced that Lisp grants programmers unprecedented power to build increasingly sophisticated artificial intelligence systems that may ultimately transform machine learning and AI research in bioinformatics and computational biology.
    [Show full text]
  • Functional Programming Laboratory 1 Programming Paradigms
    Intro 1 Functional Programming Laboratory C. Beeri 1 Programming Paradigms A programming paradigm is an approach to programming: what is a program, how are programs designed and written, and how are the goals of programs achieved by their execution. A paradigm is an idea in pure form; it is realized in a language by a set of constructs and by methodologies for using them. Languages sometimes combine several paradigms. The notion of paradigm provides a useful guide to understanding programming languages. The imperative paradigm underlies languages such as Pascal and C. The object-oriented paradigm is embodied in Smalltalk, C++ and Java. These are probably the paradigms known to the students taking this lab. We introduce functional programming by comparing it to them. 1.1 Imperative and object-oriented programming Imperative programming is based on a simple construct: A cell is a container of data, whose contents can be changed. A cell is an abstraction of a memory location. It can store data, such as integers or real numbers, or addresses of other cells. The abstraction hides the size bounds that apply to real memory, as well as the physical address space details. The variables of Pascal and C denote cells. The programming construct that allows to change the contents of a cell is assignment. In the imperative paradigm a program has, at each point of its execution, a state represented by a collection of cells and their contents. This state changes as the program executes; assignment statements change the contents of cells, other statements create and destroy cells. Yet others, such as conditional and loop statements allow the programmer to direct the control flow of the program.
    [Show full text]
  • Functional and Imperative Object-Oriented Programming in Theory and Practice
    Uppsala universitet Inst. för informatik och media Functional and Imperative Object-Oriented Programming in Theory and Practice A Study of Online Discussions in the Programming Community Per Jernlund & Martin Stenberg Kurs: Examensarbete Nivå: C Termin: VT-19 Datum: 14-06-2019 Abstract Functional programming (FP) has progressively become more prevalent and techniques from the FP paradigm has been implemented in many different Imperative object-oriented programming (OOP) languages. However, there is no indication that OOP is going out of style. Nevertheless the increased popularity in FP has sparked new discussions across the Internet between the FP and OOP communities regarding a multitude of related aspects. These discussions could provide insights into the questions and challenges faced by programmers today. This thesis investigates these online discussions in a small and contemporary scale in order to identify the most discussed aspect of FP and OOP. Once identified the statements and claims made by various discussion participants were selected and compared to literature relating to the aspects and the theory behind the paradigms in order to determine whether there was any discrepancies between practitioners and theory. It was done in order to investigate whether the practitioners had different ideas in the form of best practices that could influence theories. The most discussed aspect within FP and OOP was immutability and state relating primarily to the aspects of concurrency and performance. ​ ​ ​ ​ ​ ​ This thesis presents a selection of representative quotes that illustrate the different points of view held by groups in the community and then addresses those claims by investigating what is said in literature.
    [Show full text]
  • Functional Javascript
    www.it-ebooks.info www.it-ebooks.info Functional JavaScript Michael Fogus www.it-ebooks.info Functional JavaScript by Michael Fogus Copyright © 2013 Michael Fogus. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://my.safaribooksonline.com). For more information, contact our corporate/ institutional sales department: 800-998-9938 or [email protected]. Editor: Mary Treseler Indexer: Judith McConville Production Editor: Melanie Yarbrough Cover Designer: Karen Montgomery Copyeditor: Jasmine Kwityn Interior Designer: David Futato Proofreader: Jilly Gagnon Illustrator: Robert Romano May 2013: First Edition Revision History for the First Edition: 2013-05-24: First release See http://oreilly.com/catalog/errata.csp?isbn=9781449360726 for release details. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. Functional JavaScript, the image of an eider duck, and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc., was aware of a trade‐ mark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.
    [Show full text]
  • Automating Testing with Autofixture, Xunit.Net & Specflow
    Design Patterns Michael Heitland Oct 2015 Creational Patterns • Abstract Factory • Builder • Factory Method • Object Pool* • Prototype • Simple Factory* • Singleton (* this pattern got added later by others) Structural Patterns ● Adapter ● Bridge ● Composite ● Decorator ● Facade ● Flyweight ● Proxy Behavioural Patterns 1 ● Chain of Responsibility ● Command ● Interpreter ● Iterator ● Mediator ● Memento Behavioural Patterns 2 ● Null Object * ● Observer ● State ● Strategy ● Template Method ● Visitor Initial Acronym Concept Single responsibility principle: A class should have only a single responsibility (i.e. only one potential change in the S SRP software's specification should be able to affect the specification of the class) Open/closed principle: “Software entities … should be open O OCP for extension, but closed for modification.” Liskov substitution principle: “Objects in a program should be L LSP replaceable with instances of their subtypes without altering the correctness of that program.” See also design by contract. Interface segregation principle: “Many client-specific I ISP interfaces are better than one general-purpose interface.”[8] Dependency inversion principle: One should “Depend upon D DIP Abstractions. Do not depend upon concretions.”[8] Creational Patterns Simple Factory* Encapsulating object creation. Clients will use object interfaces. Abstract Factory Provide an interface for creating families of related or dependent objects without specifying their concrete classes. Inject the factory into the object. Dependency Inversion Principle Depend upon abstractions. Do not depend upon concrete classes. Our high-level components should not depend on our low-level components; rather, they should both depend on abstractions. Builder Separate the construction of a complex object from its implementation so that the two can vary independently. The same construction process can create different representations.
    [Show full text]
  • From JSON to JSEN Through Virtual Languages of the Creative Commons Attribution License (
    © 2021 by the authors; licensee RonPub, Lübeck, Germany. This article is an open access article distributed under the terms and conditions A.of Ceravola, the Creative F. Joublin:Commons From Attribution JSON to license JSEN through(http://c reativecommons.org/licenses/by/4Virtual Languages .0/). Open Access Open Journal of Web Technology (OJWT) Volume 8, Issue 1, 2021 www.ronpub.com/ojwt ISSN 2199-188X From JSON to JSEN through Virtual Languages Antonello Ceravola, Frank Joublin Honda Research Institute Europe GmbH, Carl Legien Str. 30, Offenbach/Main, Germany, {Antonello.Ceravola, Frank.Joublin}@honda-ri.de ABSTRACT In this paper we describe a data format suitable for storing and manipulating executable language statements that can be used for exchanging/storing programs, executing them concurrently and extending homoiconicity of the hosting language. We call it JSEN, JavaScript Executable Notation, which represents the counterpart of JSON, JavaScript Object Notation. JSON and JSEN complement each other. The former is a data format for storing and representing objects and data, while the latter has been created for exchanging/storing/executing and manipulating statements of programs. The two formats, JSON and JSEN, share some common properties, reviewed in this paper with a more extensive analysis on what the JSEN data format can provide. JSEN extends homoiconicity of the hosting language (in our case JavaScript), giving the possibility to manipulate programs in a finer grain manner than what is currently possible. This property makes definition of virtual languages (or DSL) simple and straightforward. Moreover, JSEN provides a base for implementing a type of concurrent multitasking for a single-threaded language like JavaScript.
    [Show full text]
  • The Semantics of Syntax Applying Denotational Semantics to Hygienic Macro Systems
    The Semantics of Syntax Applying Denotational Semantics to Hygienic Macro Systems Neelakantan R. Krishnaswami University of Birmingham <[email protected]> 1. Introduction body of a macro definition do not interfere with names oc- Typically, when semanticists hear the words “Scheme” or curring in the macro’s arguments. Consider this definition of and “Lisp”, what comes to mind is “untyped lambda calculus a short-circuiting operator: plus higher-order state and first-class control”. Given our (define-syntax and typical concerns, this seems to be the essence of Scheme: it (syntax-rules () is a dynamically typed applied lambda calculus that sup- ((and e1 e2) (let ((tmp e1)) ports mutable data and exposes first-class continuations to (if tmp the programmer. These features expose a complete com- e2 putational substrate to programmers so elegant that it can tmp))))) even be characterized mathematically; every monadically- representable effect can be implemented with state and first- In this definition, even if the variable tmp occurs freely class control [4]. in e2, it will not be in the scope of the variable definition However, these days even mundane languages like Java in the body of the and macro. As a result, it is important to support higher-order functions and state. So from the point interpret the body of the macro not merely as a piece of raw of view of a working programmer, the most distinctive fea- syntax, but as an alpha-equivalence class. ture of Scheme is something quite different – its support for 2.2 Open Recursion macros. The intuitive explanation is that a macro is a way of defining rewrites on abstract syntax trees.
    [Show full text]
  • Functional Programming Lecture 1: Introduction
    Functional Programming Lecture 13: FP in the Real World Viliam Lisý Artificial Intelligence Center Department of Computer Science FEE, Czech Technical University in Prague [email protected] 1 Mixed paradigm languages Functional programming is great easy parallelism and concurrency referential transparency, encapsulation compact declarative code Imperative programming is great more convenient I/O better performance in certain tasks There is no reason not to combine paradigms 2 3 Source: Wikipedia 4 Scala Quite popular with industry Multi-paradigm language • simple parallelism/concurrency • able to build enterprise solutions Runs on JVM 5 Scala vs. Haskell • Adam Szlachta's slides 6 Is Java 8 a Functional Language? Based on: https://jlordiales.me/2014/11/01/overview-java-8/ Functional language first class functions higher order functions pure functions (referential transparency) recursion closures currying and partial application 7 First class functions Previously, you could pass only classes in Java File[] directories = new File(".").listFiles(new FileFilter() { @Override public boolean accept(File pathname) { return pathname.isDirectory(); } }); Java 8 has the concept of method reference File[] directories = new File(".").listFiles(File::isDirectory); 8 Lambdas Sometimes we want a single-purpose function File[] csvFiles = new File(".").listFiles(new FileFilter() { @Override public boolean accept(File pathname) { return pathname.getAbsolutePath().endsWith("csv"); } }); Java 8 has lambda functions for that File[] csvFiles = new File(".")
    [Show full text]
  • Designpatternsphp Documentation Release 1.0
    DesignPatternsPHP Documentation Release 1.0 Dominik Liebler and contributors Jul 18, 2021 Contents 1 Patterns 3 1.1 Creational................................................3 1.1.1 Abstract Factory........................................3 1.1.2 Builder.............................................8 1.1.3 Factory Method......................................... 13 1.1.4 Pool............................................... 18 1.1.5 Prototype............................................ 21 1.1.6 Simple Factory......................................... 24 1.1.7 Singleton............................................ 26 1.1.8 Static Factory.......................................... 28 1.2 Structural................................................. 30 1.2.1 Adapter / Wrapper....................................... 31 1.2.2 Bridge.............................................. 35 1.2.3 Composite............................................ 39 1.2.4 Data Mapper.......................................... 42 1.2.5 Decorator............................................ 46 1.2.6 Dependency Injection...................................... 50 1.2.7 Facade.............................................. 53 1.2.8 Fluent Interface......................................... 56 1.2.9 Flyweight............................................ 59 1.2.10 Proxy.............................................. 62 1.2.11 Registry............................................. 66 1.3 Behavioral................................................ 69 1.3.1 Chain Of Responsibilities...................................
    [Show full text]
  • Design Patterns for QA Automation Anton Semenchenko
    Design Patterns for QA Automation Anton Semenchenko CONFIDENTIAL 1 Agenda, part 1 (general) 1. Main challenges 2. Solution 3. Design Patterns – the simplest definition 4. Design Patterns language – the simplest definition 5. Encapsulation – the most important OOP principle CONFIDENTIAL 2 Agenda, part 2 (main patterns) 1. Page Element 2. Page Object 3. Action CONFIDENTIAL 3 Agenda, part 3 (less popular patterns) 1. Flow (Fluent Interface) – Ubiquitous language – Key word driven – Behavior Driven Development (BDD) 2. Domain Specific Language (DSL) – Flow 3. Navigator (for Web) CONFIDENTIAL 4 Agenda, part 4 (take away points) 1. “Rules” and principles 2. A huge set of useful links 3. A huge set of examples CONFIDENTIAL 5 2 main challenges in our every day work (interview experience) 1. Pure design 2. Over design CONFIDENTIAL 6 Solution 1. Find a balance CONFIDENTIAL 7 Design Patterns – the simplest definition 1. Elements (blocks) of reusable object-oriented software; 2. The re-usable form of a solution to a design problem; CONFIDENTIAL 8 Design Patterns – as a language 1. Design patterns that relate to a particular field (for example QA Automation) is called a pattern language 2. Design Patterns language gives a common terminology for discussing the situations specialists are faced with: – “The elements of this language are entities called patterns”; – “Each pattern describes a problem that occurs over and over again in our (QA Automation) environment”; – “Each pattern describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice!” CONFIDENTIAL 9 Design Patterns for QA Automation 1.
    [Show full text]