- Cover
- Title Page
- Copyright
- Foreword
- Preface
- Acknowledgments
- About This Book
- About the Author
- Chapter 1: Welcome to Grokking Simplicity
- What is Functional Programming?
- The Problems with the Definition for Practical Use
- The Definition of FP Confuses Managers
- We Treat Functional Programming as a Set of Skills and Concepts
- Distinguishing Actions, Calculations, and Data
- Functional Programmers Distinguish Code That Matters When You Call It
- Functional Programmers Distinguish Inert Data From Code That Does Work
- Functional Programmers See Actions, Calculations, and Data
- The Three Categories of Code in FP
- How Does Distinguishing Actions, Calculations, and Data Help Us?
- Why is this Book Different from Other FP Books?
- What is Functional Thinking?
- Ground Rules for Ideas and Skills in this Book
- Chapter 2: Functional Thinking in Action
- Welcome to Toni’s Pizza
- Part 1: Distinguishing Actions, Calculations, and Data
- Organizing Code by “Rate of Change”
- Part 2: First-Class Abstractions
- Timelines Visualize Distributed Systems
- Multiple Timelines Can Execute in Different Orderings
- Hard-won Lessons About Distributed Systems
- Cutting the Timeline: Making the Robots Wait for Each Other
- Positive Lessons Learned About Timelines
- Part 1: Actions, Calculations, and Data
- Chapter 3: Distinguishing Actions, Calculations, and Data
- Actions, Calculations, and Data
- Actions, Calculations, and Data Apply to Any Situation
- Lessons from Our Shopping Process
- Applying Functional Thinking to New Code
- Drawing the Coupon Email Process
- Implementing the Coupon Email Process
- Applying Functional Thinking to Existing Code
- Actions Spread Through Code
- Actions Can Take Many Forms
- Chapter 4: Extracting Calculations from Actions
- Welcome to MegaMart.com!
- Calculating free Shipping
- Calculating Tax
- We Need to Make It More Testable
- We need to Make It More Reusable
- Distinguishing Actions, Calculations, and Data
- Functions Have Inputs and Outputs
- Testing and Reuse Relate to Inputs and Outputs
- Extracting a Calculation from An Action
- Extracting Another Calculation from an Action
- Let’s See All of Our Code in One Place
- Chapter 5: Improving the Design of Actions
- Aligning Design with Business Requirements
- Aligning the Function with Business Requirements
- Principle: Minimize Implicit Inputs and Outputs
- Reducing Implicit Inputs and Outputs
- Giving the Code a Once-Over
- Categorizing Our Calculations
- Principle: Design Is About Pulling Things Apart
- Improving the Design by Pulling add_item() Apart
- Extracting a Copy-On-Write Pattern
- Using add_item()
- Categorizing Our Calculations
- Smaller Functions and More Calculations
- Chapter 6: Staying Immutable in a Mutable Language
- Can Immutability be Applied Everywhere?
- Categorizing Operations into Reads, Writes, or Both
- The Three Steps of the Copy-On-Write Discipline
- Converting a Write to a Read With Copy-On-Write
- Complete Diff from Mutating to Copy-On-Write
- These Copy-On-Write Operations are Generalizable
- JavaScript Arrays at a Glance
- What to do if an Operation is a Read and a Write
- Splitting a Function that does a Read and Write
- Returning Two Values from One Function
- Reads to Immutable Data Structures are Calculations
- Applications Have State That Changes Over Time
- Immutable Data Structures are Fast Enough
- Copy-On-Write Operations on Objects
- JavaScript Objects at a Glance
- Converting Nested Writes to Reads
- What Gets Copied?
- Visualizing Shallow Copies and Structural Sharing
- Chapter 7: Staying Immutable with Untrusted Code
- Immutability with Legacy Code
- Our Copy-On-Write Code has to Interact with Untrusted Code
- Defensive Copying Defends the Immutable Original
- Implementing Defensive Copies
- The Rules of Defensive Copying
- Wrapping Untrusted Code
- Defensive Copying You May Be Familiar With
- Copy-On-Write and Defensive Copying Compared
- Deep Copies are More Expensive Than Shallow Copies
- Implementing Deep Copy in JavaScript is Difficult
- A Dialogue Between Copy-On-Write and Defensive Copying
- Chapter 8: Stratified Design: Part 1
- What is Software Design?
- What is Stratified Design?
- Developing Our Design Sense
- Patterns of Stratified Design
- Pattern 1: Straightforward Implementations
- Three Different Zoom Levels
- Extracting the for Loop
- Pattern 1 Review: Straightforward Implementation
- Chapter 9: Stratified Design: Part 2
- Patterns of Stratified Design
- Pattern 2: Abstraction Barrier
- Abstraction Barriers Hide Implementations
- Ignoring Details is Symmetrical
- Swapping the Shopping Cart’s Data Structure
- Re-Implementing the Shopping Cart as an Object
- The Abstraction Barrier Lets Us Ignore Details
- When to Use (and When ‘Not’ to Use!) Abstraction Barriers
- Pattern 2 Review: Abstraction Barrier
- Our Code is More Straightforward
- Pattern 3: Minimal Interface
- Pattern 3 Review: Minimal Interface
- Pattern 4: Comfortable Layers
- Patterns of Stratified Design
- What Does the Graph Show Us About Our Code?
- Code at the Top of the Graph is Easier to Change
- Testing Code at the Bottom is More Important
- Code at the Bottom is More Reusable
- Summary: What the Graph Shows Us About Our Code
- Part 2: First-Class Abstractions
- Chapter 10: First-Class Functions: Part 1
- Marketing Still Needs to Coordinate with Dev
- Code Smell: Implicit Argument in Function Name
- Refactoring: Express Implicit Argument
- Recognize What Is and What Isn’t First-Class
- Will Field Names as Strings Lead to More Bugs?
- Will First-Class Fields Make the API Hard to Change?
- We Will Use a Lot of Objects and Arrays
- First-Class Functions Can Replace any Syntax
- For loop example: Eating and cleaning up
- Refactoring: Replace Body with Callback
- What is this Syntax?
- Why are we Wrapping the Code in a Function?
- Chapter 11: First-Class Functions: Part 2
- One Code Smell and Two Refactorings
- Refactoring Copy-On-Write
- Refactoring Copy-On-Write for Arrays
- Returning Functions from Functions
- Chapter 12: Functional Iteration
- One Code Smell and Two Refactorings
- MegaMart is Creating a Communications Team
- Deriving map() from Examples
- Functional Tool: map()
- Three Ways to Pass a Function
- Example: Email Addresses of All Customers
- Deriving filter() from Examples
- Functional Tool: filter()
- Example: Customers with Zero Purchases
- Deriving reduce() from Examples
- Functional Tool: reduce()
- Example: Concatenating Strings
- Things You Can Do With reduce()
- Three Functional Tools Compared
- Chapter 13: Chaining Functional Tools
- The Customer Communications Team Continues
- Clarifying Chains, Method 1: Name the Steps
- Clarifying Chains, Method 2: Naming the Callbacks
- Clarifying Chains: Two Methods Compared
- Example: Emails of Customers Who Have Made One Purchase
- Refactoring Existing for Loops to Functional Tools
- Tip 1: Make Data
- Tip 2: Operate on Whole Array at Once
- Tip 3: Take Many Small Steps
- Tip 3: Take Many Small Steps
- Comparing Functional to Imperative Code
- Summary of Chaining Tips
- Debugging Tips for Chaining
- Many Other Functional Tools
- reduce() for Building Values
- Getting Creative with Data Representation
- Line Up Those Dots
- Chapter 14: Functional Tools for Nested Data
- Higher-Order Functions for Values in Objects
- Making the Field Name Explicit
- Deriving update()
- Using update() to Modify Values
- Refactoring: Replace Get, Modify, Set with update()
- Functional Tool: update()
- Visualizing Values in Objects
- Visualizing Nested Updates
- Applying update() to Nested Data
- Deriving updateOption()
- Deriving update2()
- Visualizing update2() on Nested Objects
- Writing incrementSizeByName() Four Ways
- Deriving update3()
- Deriving nestedUpdate()
- The Anatomy of Safe Recursion
- Visualizing nestedUpdate()
- The Superpower of Recursion
- Design Considerations with Deep Nesting
- Abstraction Barriers on Deeply Nested Data
- A Summary of Our Use of Higher-Order Functions
- Chapter 15: Isolating Timelines
- There’s a Bug!
- Now We Can Try to Click Twice Fast
- The Timeline Diagram Shows What Happens Over Time
- The Two Fundamentals Of Timeline Diagrams
- Two Tricky Details About the Order of Actions
- Drawing the Add-to-Cart Timeline: Step 1
- Asynchronous Calls Require New Timelines
- Different Languages, Different Threading Models
- Building the Timeline Step-by-Step
- Drawing the Add-to-Cart Timeline: Step 2
- Timeline Diagrams Capture the Two Kinds of Sequential Code
- Timeline Diagrams Capture the Uncertain Ordering of Parallel Code
- Principles of Working with Timelines
- JavaScript’s Single-Thread
- JavaScript’s Asynchronous Queue
- AJAX and the Event Queue
- A complete asynchronous example
- Simplifying the Timeline
- Reading Our Finished Timeline
- Simplifying the Add-to-Cart Timeline Diagram: Step 3
- Review: Drawing the Timeline (Steps 1–3)
- Summary: Drawing Timeline Diagrams
- Timeline Diagrams Side-by-Side Can Reveal Problems
- Two Slow Clicks Get the Right Result
- Two Fast Clicks Can Get the Wrong Result
- Timelines That Share Resources Can Cause Problems
- Converting a Global Variable to a Local One
- Converting a Global Variable to an Argument
- Making Our Code More Reusable
- Principle: In an Asynchronous Context, We Use a Final Callback Instead of a Return Value as Our Explicit Output
- Chapter 16: Sharing Resources Between Timelines
- Principles of Working with Timelines
- The Shopping Cart Still Has a Bug
- We Need to Guarantee the Order of the DOM Updates
- Building a Queue in JavaScript
- Principle: Use Real-World Sharing as Inspiration
- Making the Queue Reusable
- Analyzing the Timeline
- Principle: Analyze the Timeline Diagram to Know If There Will Be Problems
- Making the Queue Skip
- Chapter 17: Coordinating Timelines
- Principles of Working with Timelines
- There’s a Bug!
- How the Code was Changed
- Identify Actions: Step 1
- Draw Each Action: Step 2
- Simplify the Diagram: Step 3
- Possible Ordering Analysis
- Why this Timeline is Faster
- Waiting for Both Parallel Callbacks
- A Concurrency Primitive for Cutting Timelines
- Using Cut() in Our Code
- Uncertain Ordering Analysis
- Parallel Execution Analysis
- Multiple-Click Analysis
- A Primitive to Call Something Just Once
- Implicit Versus Explicit Model of Time
- Summary: Manipulating Timelines
- Chapter 18: Reactive and Onion Architectures
- Two Separate Architectural Patterns
- Coupling of Causes and Effects of Changes
- What is Reactive Architecture?
- Tradeoffs of the Reactive Architecture
- Cells are First-Class State
- We Can Make Valuecells Reactive
- We Can Update Shipping Icons When the Cell Changes
- FormulaCells Calculate Derived Values
- Mutable State in Functional Programming
- How Reactive Architecture Reconfigures Systems
- Decouples Effects from Their Causes
- Decoupling Manages a Center of Cause and Effect
- Treat Series of Steps as Pipelines
- Flexibility in Your Timeline
- Two Separate Architectural Patterns
- What is the Onion Architecture?
- Review: Actions, Calculations, and Data
- Review: Stratified Design
- Traditional Layered Architecture
- A Functional Architecture
- Facilitating Change and Reuse
- Examine the Terms Used to Place the Rule in a Layer
- Analyze Readability and Awkwardness
- Chapter 19: The Functional Journey Ahead
- A Plan for the Chapter
- We Have Learned the Skills of Professionals
- Big Takeaways
- The Ups and Downs of Skill Acquisition
- Parallel Tracks to Mastery
- Sandbox: Start a Side Project
- Sandbox: Practice Exercises
- Production: Eliminate a Bug Today
- Production: Incrementally Improve the Design
- Popular Functional Languages
- Functional Languages with the Most Jobs
- Functional Languages by Platform
- Functional Languages by Learning Opportunity
- Get Mathy
- Further Reading
- Index
-
No Comment
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.