Scala与Clojure函数式编程模式实用指南

需积分: 9 20 浏览量更新于2024-07-18 收藏 6.13MB PDF 举报

《Pragmatic Bookshelf》的《Functional Programming Patterns in Scala and Clojure》是一本专为想要从面向对象（Object-Oriented, OO）编程过渡到函数式编程（Functional Programming, FP）的开发者精心编写的指南。本书由经验丰富的作者撰写，旨在为那些在Java Virtual Machine (JVM)环境中工作的程序员揭示函数式编程的力量。这本书的核心价值在于它提供了一个实用且系统的方法，帮助读者理解和掌握函数式编程中的核心模式。作者巧妙地将这些模式分为两个部分：一部分是函数式编程的原生模式，另一部分则是与OO模式相对应的函数式替代方案。这种结构使得本书成为了一种方便的参考资源，无论是Scala开发者还是希望学习新技巧的读者都能从中受益。对于那些已经对Clojure或Scala有所接触但尚未完全熟悉这两种语言的开发者来说，本书尤其有价值。特别是对于那些熟练的面向对象程序员，它提供了逐步转换的路径，指导他们如何逐渐摆脱熟悉的OO设计模式，拥抱函数式的思维方式和编程风格。评论家Colin Yates，作为QFI Consulting LLP的技术团队领队，高度赞扬了这本书，认为它是必读之作，是一个在两种截然不同的编程范式之间搭建桥梁的安全绳索。Justin James，作为Full Stack Apps的一名开发者，也表示这本书适合有一定基础的Clojure或Scala用户，尤其是那些寻求改变并寻求向函数式编程转变的资深程序员。《Functional Programming Patterns in Scala and Clojure》不仅提供了深入浅出的函数式编程实践，还为读者提供了实用的转型策略，无论你是希望精通这两种语言，还是希望扩展自己的编程技能库，这都是一本不容错过的书籍。通过阅读和实践书中的模式，开发者可以提升代码的简洁性、可读性和可维护性，从而在现代软件开发中占据优势。

are solved in a simpler way. Developers prefer the built-in

foreach

loops for the

common-sense reasons that they are less work to implement and are less

error prone.

Many functional language features and techniques have a similar effect on

coding projects. While they may not be the exact equivalent to a pattern, they

often provide developers with a built-in alternative that solves the same

problem. Similar to the

foreach

-Iterator example, other language features give

programmers techniques that are less work and often produce code that is

more concise and easier to understand than the original.

Adding functional features and techniques adds more tools to our program-

ming toolbox, just as Java 1.5 did with its

foreach

loop but on a grander scale.

These tools often complement the tools we already know and love from the

object-oriented world.

The second set of patterns we cover in this book, native functional patterns,

describes the patterns that evolved out of the functional style. These functional

patterns differ from the object-oriented patterns you may be familiar with in

a few key ways. The first, and most obvious, is that functions are the primary

unit of composition, just as objects are in the object-oriented world.

Another key difference lies in the patterns’ granularity. The patterns from

Design Patterns: Elements of Reusable Object-Oriented Software [GHJV95] (one

of the original drivers of the software patterns movement) are generally tem-

plates that define a few classes and specify how they fit together. Most of

them are medium size. They often don’t concern themselves either with very

small issues that encompass just a few lines of code or with very large issues

that encompass entire programs.

The functional patterns in this book cover a much broader range, as some of

them can be implemented in a line or two of code. Others tackle very big

problems, such as creating new, miniature programming languages.

The range is in line with the book that started the patterns movement in

general, A Pattern Language [AIS77]. This book on architectural patterns

starts off with the very big “1—Independent Regions” pattern, which outlines

why the planet should be organized into political entities of about 10,000

people, and goes all the way down to “248—Soft Tile and Brick,” which explains

how to make your own bricks.

Before we dig into the various patterns in this book, let’s spend some time

getting familiar with functional programming itself.

Chapter 1. Patterns and Functional Programming • 2

report erratum • discuss

Download from Wow! eBook <www.wowebook.com>

1.1 What Is Functional Programming?

At its core, functional programming is about immutability and about compos-

ing functions rather than objects. Many related characteristics fall out of this

style.

Functional programs do the following:

Have first-class functions: First-class functions are functions that can be

passed around, dynamically created, stored in data structures, and

treated like any other first-class object in the language.

Favor pure functions: Pure functions are functions that have no side effects.

A side effect is an action that the function does that modifies state outside

the function.

Compose functions: Functional programming favors building programs from

the bottom up by composing functions together.

Use expressions: Functional programming favors expressions over statements.

Expressions yield values. Statements do not and exist only to control the

flow of a program.

Use Immutability: Since functional programming favors pure functions, which

can’t mutate data, it also makes heavy use of immutable data. Instead of

modifying an existing data structure, a new one is efficiently created.

Transform, rather than mutate, data: Functional programming uses functions

to transform immutable data. One data structure is put into the function,

and a new immutable data structure comes out. This is in explicit contrast

with the popular object-oriented model, which views objects as little

packets of mutable state and behavior.

A focus on immutable data leads to programs that are written in a more

declarative style, since we can’t modify a data structure piece by piece. Here’s

an iterative way to filter the odd numbers out of a list, written in Java. Notice

how it relies on mutation to add odd numbers to

filteredList

one at a time.

JavaExamples/src/main/java/com/mblinn/mbfpp/intro/FilterOdds.java

public List<Integer> filterOdds(List<Integer> list) {

List<Integer> filteredList = new ArrayList<Integer>();

for (Integer current : list) {

if (isOdd(current)) {

filteredList.add(current);

}

return filteredList;

}

report erratum • discuss

What Is Functional Programming? • 3

Download from Wow! eBook <www.wowebook.com>

private boolean isOdd(Integer integer) {

return 0 != integer % 2;

}

And here’s a functional version, written in Clojure.

(filter odd? list-of-ints)

The functional version is obviously much shorter than the object-oriented

version. As mentioned previously, this is because functional programming is

declarative. That is, it specifies what should be done rather than how to do

it. For many problems we encounter in programming, this style lets us work

at a higher level of abstraction.

However, other problems are hard, if not impossible, to solve using strict

functional programming techniques. A compiler is a pure function. If you put

a program in, you expect to get the same machine code out every time. If you

don’t, it’s probably a compiler bug. Google’s search engine, however, is not a

pure function. If we got the same results from a Google search query every

time, we’d be stuck with a late 1990s view of the Web, which would be quite

tragic.

For this reason, functional programming languages tend to lie on a spectrum

of strictness. Some are more functionally pure than others. Of the two lan-

guages we’re using in this book, Clojure is purer on the functional spectrum;

at least, it is if we avoid its Java interoperability features.

For example, in idiomatic Clojure, we don’t mutate data as we do in Java.

Instead, we rely on an efficient set of immutable data structures, a set of ref-

erence types, and a software transactional memory system. This allows us to

get the benefits of mutability without the dangers. We’ll introduce these

techniques in Section 2.4, TinyWeb in Clojure, on page 28.

Scala has more support for mutable data, but immutable data is preferred.

For instance, Scala has both mutable and immutable versions of its collections

library, but the immutable data structures are imported and used by default.

1.2 Pattern Glossary

Here is where we introduce all of the patterns we cover in the book and give

a brief overview of each. This is a great list to skim if you already have a

specific problem you need to solve in a functional way.

Chapter 1. Patterns and Functional Programming • 4

report erratum • discuss

Download from Wow! eBook <www.wowebook.com>

Replacing Object-Oriented Patterns

This section shows how to replace common object-oriented patterns with

functional language features. This generally cuts down on the amount of code

we have to write while giving us a more concise code to maintain.

Pattern 1, Replacing Functional Interface, on page 40

Here we replace common types of functional interfaces, such as

Runnable

Comparator

, with native functional features.

This section introduces two basic types of functional features. The first type,

higher-order functions, allows us to pass functions around as first-class data.

The second, anonymous functions, allows us to write quick one-off functions

without giving them a name. These features combine to let us replace most

instances of Functional Interface very concisely.

Pattern 2, Replacing State-Carrying Functional Interface, on page 47

With this pattern we replace instances of Functional Interface that need to

carry around some bit of state—we introduce another new functional feature,

closures, which lets us wrap up a function and some state to pass around.

Pattern 3, Replacing Command, on page 54

Replacing Command encapsulates an action in an object—here we’ll take a

look at how we can replace the object-oriented version using the techniques

introduced in the previous two patterns.

Pattern 4, Replacing Builder for Immutable Object, on page 62

Here we carry data using the classic Java convention, a class full of getters

and setters—this approach is intimately tied up with mutability. Here we’ll

show how to get the convenience of a Java Bean along with the benefits of

immutability.

Pattern 5, Replacing Iterator, on page 72

Replacing Iterator gives us a way to access items in a collection sequential-

ly—here we’ll see how we can solve many of the problems we’d solve with

Iterator using higher-order functions and sequence comprehensions, which

give us solutions that are more declarative.

Pattern 6, Replacing Template Method, on page 83

This pattern defines the outline of an algorithm in a superclass, leaving

subclasses to implement its details. Here we’ll see how to use higher-order

functions and function composition to replace this inheritance-based pattern.

report erratum • discuss

Pattern Glossary • 5

Download from Wow! eBook <www.wowebook.com>

Pattern 7, Replacing Strategy, on page 92

In this pattern we define a set of algorithms that all implement a common

interface. This allows a programmer to easily swap out one implementation

of an algorithm for another.

Pattern 8, Replacing Null Object, on page 99

In this pattern we discuss how to replace Null Object and talk about other

types of null handling—in Scala, we take advantage of the type system using

Option

. In Clojure, we rely on

nil

and some language support to make it more

convenient to deal with.

Pattern 9, Replacing Decorator, on page 109

Replacing Decorator adds new behavior to an object without changing the

original class. Here we’ll see how to achieve the same effect with function

composition.

Pattern 10, Replacing Visitor, on page 113

Replacing Visitor makes it easy to add operations to a data type but difficult

to add new implementations of the type. Here we show solutions in Scala and

Clojure that make it possible to do both.

Pattern 11, Replacing Dependency Injection, on page 128

This pattern injects an object’s dependencies into it, rather than instantiating

them inline—this allows us to swap out their implementations. We’ll explore

Scala’s Cake pattern, which gives us a DI-like pattern.

Introducing Functional Patterns

Pattern 12, Tail Recursion, on page 138

Tail Recursion is functionally equivalent to iteration and provides a way to

write a recursive algorithm without requiring a stack frame for each recursive

call. While we’ll prefer more declarative solutions throughout the book,

sometimes the most straightforward way to solve a problem is more iterative.

Here we’ll show how to use Tail Recursion for those situations.

Pattern 13, Mutual Recursion, on page 146

Mutual Recursion is a pattern where recursive functions call one another. As

with Tail Recursion, we need a way to do this without consuming stack frames

for it to be practical. Here we’ll show how to use a feature called trampolining

to do just that.

Chapter 1. Patterns and Functional Programming • 6

report erratum • discuss

Download from Wow! eBook <www.wowebook.com>

剩余252页未读，继续阅读

s63923633

粉丝: 0
资源: 8

Scala与Clojure函数式编程模式实用指南

Scala Functional Programming Patterns

Functional Programming in Scala

Functional Programming Patterns in Scala and Clojure(Pragmatic,2013)

Pragmatic Bookshelf, Programming Ruby 2nd

pragmatic.bookshelf.programming.clojure

Pragmatic Bookshelf Pragmatic Unit Testing in CSharp with NUnit 2nd Edition

Pragmatic.Bookshelf.Programming.Groovy

Pragmatic Bookshelf - Release It! Design and Deploy Production Ready Software.pdf

Programming Ruby 1.9 (Pragmatic Bookshelf 2009).pdf

Noel Rappin, Dave Thomas - Programming Ruby 3.2_ The Pragmatic Programmers' Guide-Pragmatic Bookshelf (2023).pdf

最新资源