Scala与Clojure的函数式编程模式

需积分: 10 148 浏览量更新于2024-07-22 收藏 6.57MB PDF 举报

"Functional Programming Patterns in Scala and Clojure(Pragmatic,2013)" 是一本面向有经验的Java程序员的书籍，旨在介绍Scala和Clojure这两种在JVM上运行并能与Java互操作的实用、生产级别的编程语言。通过这本书，读者将了解如何利用函数式编程解决实际问题，使用更简洁的代码来替代纯面向对象编程中的大量代码，从而提高代码的声明性，减少错误并降低维护成本。书中包含两部分模式：一是面向对象模式在函数式编程中的简化应用，二是原生的函数式模式。这种划分有助于读者逐步过渡到函数式编程的世界。对于那些已经接触过Scala或Clojure但还不太熟练的开发者来说，这本书是理想的读物；同时，它也适合想要采用函数式风格的资深面向对象程序员，为他们提供了一个从熟悉的设计模式转向函数式模式的指南。作者详细介绍了如何用Scala和Clojure实现这些模式，包括静态类型、类型推断的Scala以及动态类型的现代LispClojure。书中提供的案例研究和深入问题解决方法，使读者能够在实践中学习和理解函数式编程的优势。作为Clojure和Scala的开发者，你将发现这本书不仅提供了对函数式编程概念的深入理解，还包含了一些新的编程技巧和策略。例如，如何使用Clojure的函数式特性来简化代码，以及如何利用Scala的特质（traits）和高阶函数等特性来实现更高效的设计。书中的内容将帮助你理解： 1. 函数式编程的基本原理，如纯函数、不可变数据结构和副作用的最小化。 2. 如何在Scala和Clojure中实现函数式设计模式，如高阶函数、闭包、柯里化和递归。 3. 类型系统在Scala中的作用，以及如何在没有类型系统的Clojure中保持代码的健壮性。 4. 使用Scala的Actor模型进行并发处理，以及Clojure的agent和atom等并发工具。 5. 如何将函数式编程思想应用于面向对象的设计模式，如工厂、单例、装饰器和适配器等。 6. Scala和Clojure如何与Java库和框架集成，以及如何编写可维护的跨语言代码。《Functional Programming Patterns in Scala and Clojure》是一本深度和实用性兼备的书籍，它不仅提供了丰富的实例来展示函数式编程的强大之处，还帮助读者建立起从传统面向对象到现代函数式编程的桥梁，提升开发效率和代码质量。对于任何寻求编程技术进阶的Java开发者来说，这是一本不容错过的资源。

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

www.it-ebooks.info

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

www.it-ebooks.info

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

www.it-ebooks.info

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

www.it-ebooks.info

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

www.it-ebooks.info

剩余252页未读，继续阅读

vanridin

粉丝: 108
资源: 1187

Scala与Clojure的函数式编程模式

Functional Programming Patterns in Scala and Clojure 无水印pdf

Functional Programming Patterns in Scala and Clojure epub

23 design patterns in C++ code

modern c++ design: generic programming and design patterns pdf

23 design patterns in C code

如何解决java: patterns in switch statements 是预览功能，默认情况下禁用。 （请使用 --enable-preview 以启用 patterns in switch statements）

game programming patterns

java近几年英文文献,Java演进英文文献和中文翻译

the charcacter data in row and column

thinking in patterns 百度百科

最新资源

如何解决java: patterns in switch statements 是预览功能，默认情况下禁用。（请使用 --enable-preview 以启用 patterns in switch statements）