Becoming Functional (Joshua Backfield) (Z-Library)

📄 File Format: PDF

💾 File Size: 7.0 MB

📖 Read Online ⬇️ Download

Registered users can read the full content for free

Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.

📄 Page 1

(This page has no text content)

📄 Page 2

(This page has no text content)

📄 Page 3

Joshua Backfield Becoming Functional

📄 Page 4

Becoming Functional by Joshua Backfield Copyright © 2014 Joshua Backfield. 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 corporate@oreilly.com. Editors: Meghan Blanchette and Brian Anderson Production Editor: Kristen Brown Copyeditor: Rachel Monaghan Proofreader: Becca Freed Indexer: Ellen Troutman Cover Designer: Karen Montgomery Interior Designer: David Futato Illustrator: Rebecca Demarest July 2014: First Edition Revision History for the First Edition: 2014-06-30: First release See http://oreilly.com/catalog/errata.csp?isbn=9781449368173 for release details. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. Becoming Functional, the image of a sheldrake 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. ISBN: 978-1-449-36817-3 [LSI]

📄 Page 5

Table of Contents Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Overview of Concepts in Functional Programming 1 First-Class Functions 2 Pure Functions 2 Recursion 2 Immutable Variables 2 Nonstrict Evaluation 2 Statements 2 Pattern Matching 2 Functional Programming and Concurrency 3 Conclusion 3 2. First-Class Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Introduction to XXY 5 Functions as Objects 7 Refactoring Using If-Else Structures 8 Refactoring Using Function Objects to Extract Fields 10 Anonymous Functions 16 Lambda Functions 16 Closures 18 Higher-Order Functions 20 Refactoring get Functions by Using Groovy 22 Conclusion 23 3. Pure Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Output Depends on Input 25 Purifying Our Functions 29 iii

📄 Page 6

Side Effects 33 Conclusion 37 Making the Switch to Groovy 38 4. Immutable Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Mutability 43 Immutability 48 Conclusion 54 5. Recursion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 An Introduction to Recursion 56 Recursion 59 Tail Recursion 61 Refactoring Our countEnabledCustomersWithNoEnabledContacts Function 62 Conclusion 64 Introducing Scala 65 6. Strict and Nonstrict Evaluations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Strict Evaluation 68 Nonstrict (Lazy) Evaluation 69 Laziness Can Create Problems 73 Conclusion 76 7. Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Taking the Plunge 80 Simple Statements 80 Block Statements 82 Everything Is a Statement 84 Conclusion 92 8. Pattern Matching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Simple Matches 93 Simple Patterns 95 Extracting Lists 97 Extracting Objects 99 Converting to Pattern Matches 101 Conclusion 103 9. Functional OOP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Static Encapsulation 105 Objects As Containers 107 Code as Data 109 iv | Table of Contents

📄 Page 7

Conclusion 111 10. Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 From Imperative to Functional 113 Introduce Higher-Order Functions 113 Convert Existing Methods into Pure Functions 114 Convert Loops to Tail/Recursive-Tail Methods 114 Convert Mutable Variables into Immutable Variables 115 What Next? 115 New Design Patterns 115 Message Passing for Concurrency 115 The Option Pattern (Extension of Null Object Pattern) 116 Object to Singleton Method Purity 117 Putting It All Together 117 Conclusion 125 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Table of Contents | v

📄 Page 8

(This page has no text content)

📄 Page 9

Preface Although not a new concept, functional programming has started to take a larger hold in the programming community. Features such as immutable variables and pure func‐ tions have proven helpful when we have to debug code, and higher-order functions make it possible for us to extract the inner workings of functions and write less code over time. All of this leads to more expressive code. Who Is This Book For? I wrote this book for anyone who is interested in functional programming or is looking to transition from an imperative style to a functional one. If you’ve been programming in an imperative or object-oriented style, my hope is that you’ll be able to pick up this book and start learning how to code in a functional one instead. This book will teach you how to recognize patterns in an imperative style and then walk you through how to transition into a more functional one. We will approach this by looking at a fictional company called XXY and look at their legacy code. We’ll then refactor its legacy code from an imperative style into a functional one. We’re going to use a few different languages throughout this book: Java I assume that you are familiar with the Java syntax. The version used in this book is 1.7.0. Groovy Using this language, we can keep most of our existing Java syntax; this helps us begin our transition into a fully functional language. I’ll explain the main parts of the Groovy syntax as they are needed. The version used in this book is 2.0.4. vii

📄 Page 10

Scala This is a fully functional language into which we will slowly transition. As with Groovy, I will explain the syntax as it is introduced. The version used in this book is 2.10.0. Why No Java 8? Some people might wonder why I’m not including any Java 8 right now. As of this writing, Java 7 is the currently stable and widely used version. Because I want everyone, not just early adopters, to be able to take something from this book, I thought starting from Java 7 would be most accessible. Those using Java 8 will be able to use some of the Groovy concepts, such as higher-order functions, without actually transitioning into Groovy. Math Notation Review Because functional programming is so closely tied to mathematics, let’s go over some basic mathematical notation. Functions in mathematics are represented with a name(parameters) = body style. The example in Equation P-1 shows a very simple function. The name is f, the parameter list is x, the body is x + 1, and the return is the numeric result of x + 1. Equation P-1. A simple math function f (x) = x + 1 if statements in math are represented by the array notation. We will have a list of operations in which one will be evaluated when the corresponding if statement is true. The simple example in Equation P-2 shows a set of statements to be evaluated. The function abs(x) will return x * -1 if our x is less than 0; otherwise, it will return x. Equation P-2. A simple math if statement abs(x) = {x * - 1 if x < 0 x else We also use a summation, the sigma operator, in our notation. The example in Equation P-3 shows a simple summation. The notation says to have a variable n starting at 0 (defined by the n=0 below the sigma) and continuing to x (as defined by the x above viii | Preface

📄 Page 11

the sigma). Then, for each n we add it to our sum (defined by the body, n in our case, to the right of the sigma). Equation P-3. A simple math summation f (x) = ∑ n=0 x n Why Functional over Imperative? There are quite a few paradigms, each with its own pros and cons. Imperative, func‐ tional, event-driven—all of these paradigms represent another way of programming. Most people are familiar with the imperative style because it is the most common style of programming. Languages such as Java and C languages are all imperative by design. Java incorporates object-oriented programming (OOP) into its language, but it still primarily uses an imperative paradigm. One of the most common questions I’ve heard during my time in software is “why should I bother learning functional programming?” Because most of my new projects have been in languages like Scala, the easiest response I can give is “that is what the project is written in.” But let’s take a step back and actually answer the question in depth. I’ve seen quite a bit of imperative code that requires cryptographers to fully understand what it does. Generally, with the imperative style, you can write code and make it up as you go. You can write classes upon classes without fully understanding what the im‐ plementation will be. This usually results in a very large, unsustainable code base filled with an overuse of classes and spaghetti code. Functional programming, on the other hand, forces us to better understand our im‐ plementation before and while we’re coding. We can then use that to identify where abstractions should go and reduce the lines of code we have written to execute the same functionality. Why Functional Alongside OOP? When we think of OOP, we normally think of a paradigm that is in a class of its own. But if we look at how we write OOP, the OOP is really used for encapsulation of variables into objects. Our code is actually in the imperative style—that is, it is executed “top to bottom.” As we transition to functional programming, we’ll see many more instances in which we just pass function returns into other functions. Some people see functional programming as a replacement for OOP, but in fact we’ll still use OOP so that we can continue using objects that can maintain methods. These methods, hoever, will usually call static versions that allow us to have purer and more Preface | ix

📄 Page 12

testable functions. So, we’re not replacing OOP; rather, we’re using object-oriented de‐ sign in a functional construct. Why Functional Programming Is Important Concepts such as design patterns in Java are so integral to our daily programming that it’s almost impossible to imagine life without them. So it is very interesting that, by contrast, the functional style has been around for many years but remains in the back‐ ground as a main programming paradigm. Why, then, is functional programming becoming so much more important today if it’s been around so long? Well, think back to the dot-com era, a time when any web presence was better than none. And what about general applications? As long as the application worked, nobody cared about the language or paradigm in which it was written. Requirements and expectations today are difficult, so being able to closely mirror math‐ ematical functions allows engineers to design strong algorithms in advance and rely on developers to implement those algorithms within the time frame required. The closer we bind ourselves to a mathematical underpinning, the better understood our algo‐ rithms will be. Functional programming also allows us to apply mathematics on those functions. Using concepts such as derivatives, limits, and integrals on functions can be useful when we are trying to identify where functions might fail. Large functions are not very testable and also not very readable. Often, as software developers, we find ourselves presented with large chunks of functionality thrown into one function. But, if we extract the inner workings of these large, cumbersome functions into multiple, smaller, more understandable functions, we allow for more code reuse as well as higher levels of testing. Code reuse and higher levels of testing are two of the most important benefits of moving to a functional language. Being able to extract entire chunks of functionality from a function makes it possible for us to change the functionality later without using a copy- and-paste methodology. Conventions Used in This Book The following typographical conventions are used in this book: Italic Indicates new terms, URLs, email addresses, filenames, and file extensions. Constant width Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords. x | Preface

📄 Page 13

Constant width bold Shows commands or other text that should be typed literally by the user. Constant width italic Shows text that should be replaced with user-supplied values or by values deter‐ mined by context. This icon signifies a tip, suggestion, or general note. This icon indicates a warning or caution. Math Warning Every now and again, I’ll introduce some mathematics; I’ll try to warn you beforehand. Check out the section “Math Notation Review” on page viii if you are rusty on reading mathematical notations. Using Code Examples Supplemental material (code examples, exercises, etc.) is available for download at https://github.com/jbackfield/BecomingFunctional. This book is here to help you get your job done. In general, if example code is offered with this book, you may use it in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of ex‐ ample code from this book into your product’s documentation does require permission. We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “Becoming Functional by Joshua Backfield (O’Reilly). Copyright 2014 Joshua Backfield, 978-1-449-36817-3.” If you feel your use of code examples falls outside fair use or the aforementioned per‐ mission, feel free to contact us at permissions@oreilly.com. Preface | xi

📄 Page 14

Safari® Books Online Safari Books Online is an on-demand digital library that delivers expert content in both book and video form from the world’s leading authors in technology and business. Technology professionals, software developers, web designers, and business and crea‐ tive professionals use Safari Books Online as their primary resource for research, prob‐ lem solving, learning, and certification training. Safari Books Online offers a range of product mixes and pricing programs for organi‐ zations, government agencies, and individuals. Subscribers have access to thousands of books, training videos, and prepublication manuscripts in one fully searchable database from publishers like O’Reilly Media, Prentice Hall Professional, Addison-Wesley Pro‐ fessional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Technol‐ ogy, and dozens more. For more information about Safari Books Online, please visit us online. How to Contact Us Please address comments and questions concerning this book to the publisher: O’Reilly Media, Inc. 1005 Gravenstein Highway North Sebastopol, CA 95472 800-998-9938 (in the United States or Canada) 707-829-0515 (international or local) 707-829-0104 (fax) We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at http://bit.ly/becoming-functional. To comment or ask technical questions about this book, send email to bookques tions@oreilly.com. For more information about our books, courses, conferences, and news, see our website at http://www.oreilly.com. Find us on Facebook: http://facebook.com/oreilly Follow us on Twitter: http://twitter.com/oreillymedia Watch us on YouTube: http://www.youtube.com/oreillymedia xii | Preface

📄 Page 15

Acknowledgments I’d like to thank my wife, Teri, and my daughter, Alyssa, for putting up with me during the writing of this book. I’d also like to thank Kevin Schmidt for introducing me to Simon St.Laurent, who made this book a reality, and my bosses, Gary Herndon and Alan Honeycutt, for allowing me to push the boundaries at work and try new things. I’d especially like to thank Meghan Blanchette, who kept moving me along and made sure that I was continuing to make progress along the way. Finally, I want to thank my parents, Sue and Fred Backfield, for believing in me and pushing me to continue learning and growing when I was a kid. If it weren’t for all of you making a difference in my life, I wouldn’t be here sharing my knowledge with so many other aspiring developers today. There are lots of other people I’ve met along the way who have helped me become a better developer; I know I’m going to leave people out (and I’m sorry if I do), but here is a good attempt at a list: Nick Angus, Johnny Calhoun, Jason Pinkey, Ryan Karetas, Isaac Henry, Jim Williams, Mike Wisener, Yatin Kanetkar, Sean McNealy, Christopher Heath, and Dave Slusher. Preface | xiii

📄 Page 16

(This page has no text content)

📄 Page 17

CHAPTER 1 Introduction Our first step before we get into actual examples is to look at what defines functional programming. Specifically, we will look at the components that make up functional programming and how they relate to mathematics. Functional programming traces its roots all the way back to LISP, although the paradigm name itself wasn’t truly coined until John Backus delivered his 1977 Turing Award–winning paper “Can Pro‐ gramming Be Liberated From the von Neumann Style? A Function‐ al Style and Its Algebra of Programs.” In his lecture, Backus discuss‐ es multiple points about applications being built as combinations of algebraic equations. Overview of Concepts in Functional Programming Although there is still some disagreement about what functional programming is, there are a few features that are generally agreed to be part of it: • First-class functions • Pure functions • Recursion • Immutable variables • Nonstrict evaluation • Statements • Pattern matching 1

📄 Page 18

First-Class Functions First-class functions can either accept another function as an argument or return a function. Being able to create functions and return them or pass them to other functions becomes extremely useful in code reusability and code abstractions. Pure Functions Pure functions are functions that have no side effects. Side effects are actions a function may perform that are not solely contained within the function itself. When we think about side effects, we normally think about other functions, such as println or mutating a global variable. We can also see this when we pass in a variable and mutate it directly inside of that function. Recursion Recursion allows us to write smaller, more concise algorithms and to operate by looking only at the inputs to our functions. This means that our function is concerned only with the iteration it is on at the moment and whether it must continue. Immutable Variables Immutable variables, once set, cannot be changed. Although immutability seems very difficult to do, given the fact that the state must change within an application at some point, we’ll see ways that we can accomplish it. Nonstrict Evaluation Nonstrict evaluations allow us to have variables that have not been computed yet. Strict evaluations—assigning a variable as soon as it is defined—are what we are used to. Nonstrict means that we can have a variable that does not get assigned (computed) until the first time it is referenced. Statements Statements are evaluable pieces of code that have a return value. Think about if state‐ ments that have a return value of some kind. Each line of code should be considered a statement, meaning there are very few side effects within the application itself. Pattern Matching Pattern matching doesn’t really appear in mathematics, but assists functional program‐ ming in decreasing the need for specific variables. In code we usually encapsulate a group of variables together inside of an object. Pattern matching allows us to better 2 | Chapter 1: Introduction

📄 Page 19

type-check and extract elements from an object, making for simpler and more concise statements with less need for variable definitions. Functional Programming and Concurrency Concurrency enables us to do processing in parallel, and we won’t cover much about it here because the topic could fill its own book. Some people believe that functional programming actually solves concurrency issues, but this is not actually the case; rather, some of the concepts of functional programming help us to create more well-defined patterns to handle concurrency. For example, techniques such as message passing help us to create more independent threads by allowing a thread to receive messages without causing another thread to block before it is received. In addition, features such as immutability help us to define global states and allow global state transitions as a whole rather than partial state changes or major synchronizations between threads. Conclusion This chapter was intended as a high-level overview of the important concepts of func‐ tional programming. At this point you’re probably wondering “how can I actually get started using these concepts?” As we go through this book, we’ll look at how to imple‐ ment these features in your code. In each chapter, I’ll introduce a concept, and then we’ll work to refactor and implement it in our example code for the ficticious company XXY. The examples have no “driver code.” I assume that everyone reading this book can write simple Java main() functions to test out the code we’re writing. I’m doing this for two reasons. First, I really want you to write the code and test it out yourself; just reading the examples isn’t going to help you understand the concepts or help you become a better functional programmer. Second, I want to draw attention away from the driver code. Sometimes, when writing more extraneous code to actually call the code that we’re refactoring, we either forget to refactor the driver code or tend to write too much. Would it really be useful to create a set of driver code to create 10 or 20 Customer objects? Each language example is compilable and runnable. The language examples will not rely on external packages. One of the things I truly dislike about some concept books or language books is that normally the author will push you to download third-party packages. In contrast, the goal of this book is to teach you how to deal with functional concepts using the core language. Functional Programming and Concurrency | 3

📄 Page 20

(This page has no text content)