1 简介
管道能够清晰的表达多步操作过程。那么管道到底是如何工作的呢？有哪些方法可以替代管道呢？在什么情况下不能使用管道呢？接下来我们将一步步讨论。
1.1 加载包
管道符：%>%是来自Stefan Milton Bache的magrittr包。tidyverse 中的包%>%会自动加载，因此我们不需要加载 magrittr。为了突出管道来源的包，我们先加载它。
library(magrittr)
2 管道替代方案
管道的目的是帮助您以更易于阅读和理解编写的代码。为了了解管道为何如此有用，通过编写多种相同代码来比较。下面来看一个关于一只名叫 Foo Foo 的小兔子的故事：
Little bunny Foo Foo
Went hopping through the forest
Scooping up the field mice
And bopping them on the head
这是一首英语流行儿童诗。
我们将首先定义一个对象来代表小兔子 Foo Foo：
foo_foo <- little_bunny()
我们将为每个关键动作使用一个函数:hop()、scoop()和bop()。使用这个对象和这些动做，我们可以(至少)有四种方式在代码中复述这个故事:
- 将每个中间步骤保存为一个新对象。
- 多次覆盖原始对象。
- 编写函数。
- 使用管道。
我们将研究每种方法，展示代码优缺点。
2.1 中间步骤
最简单的方法是将每个步骤保存为一个新对象：
foo_foo_1 <- hop(foo_foo, through = forest)
foo_foo_2 <- scoop(foo_foo_1, up = field_mice)
foo_foo_3 <- bop(foo_foo_2, on = head)
这种方法的的主要缺点是你必须为每个中间元素命名。
实际的数据管道操作，我们在其中添加了一个新列ggplot2::diamonds：
diamonds <- ggplot2::diamonds
diamonds2 <- diamonds %>%
dplyr::mutate(price_per_carat = price / carat)
pryr::object_size(diamonds)
#> Registered S3 method overwritten by 'pryr':
#> method from
#> print.bytes Rcpp
#> 3.46 MB
pryr::object_size(diamonds2)
#> 3.89 MB
pryr::object_size(diamonds, diamonds2)
#> 3.89 MB
pryr::object_size()给出其所有参数占用的内存。然而一看结果觉得不可思议：
-
diamonds占用 3.46 MB， -
diamonds2占用 3.89 MB， -
diamonds和diamonds2一起占用 3.89 MB！
这是怎么回事呢？diamonds2与diamonds有 10 列： 没有必要复制所有数据，所以两个数据框拥有共同的变量。如果修改其中一个变量，这个变量会被复制。在下面例子中，修改了diamonds$carat. 这意味着carat变量不能再在两个数据帧之间共享，必须进行复制。每个数据帧的大小不变，但集体大小增加：
diamonds$carat[1] <- NA
pryr::object_size(diamonds)
#> 3.46 MB
pryr::object_size(diamonds2)
#> 3.89 MB
pryr::object_size(diamonds, diamonds2)
#> 4.32 MB
2.2 覆盖对象
我们可以直接覆盖原始对象，而需要在每一步都创建中间对象：
foo_foo <- hop(foo_foo, through = forest)
foo_foo <- scoop(foo_foo, up = field_mice)
foo_foo <- bop(foo_foo, on = head)
这是更少的打字（和更少的思考），所以你不太可能犯错误。但是，有两个问题：
不方便调试：如果你某一步出现了错误，你需要从头开始重新运行 。
对象名重复使用（我们已经写了
foo_foo六次！）掩盖了每一行的变化。
2.3 构造函数
直接合并函数调用：
bop(
scoop(
hop(foo_foo, through = forest),
up = field_mice
),
on = head
)
这里的缺点是你必须从里到外，从右到左阅读，代码阅读起来困难。
2.4 使用管道
最后，我们可以使用管道：
foo_foo %>%
hop(through = forest) %>%
scoop(up = field_mice) %>%
bop(on = head)
这是我最喜欢的形式，因为它侧重于每一步操作，可以直接阅读这一系列的函数组合，就像它是一组命令式操作。Foo Foo ，hop，scoop，最后是bops。
管道通过执行“词法转换”来工作：在实际运行时，magrittr将管道中的代码重组为一种形式，这种形式通过覆盖一个中间对象来工作。当你运行一个像上面这样的管道时，magrittr会这样做：
my_pipe <- function(.) {
. <- hop(., through = forest)
. <- scoop(., up = field_mice)
bop(., on = head)
}
my_pipe(foo_foo)
这意味着管道不适用于两类函数：
-
使用当前环境的函数。例如，
assign()在当前环境中创建一个具有给定名称的新变量：assign("x", 10) x #> [1] 10 "x" %>% assign(100) x #> [1] 10对管道使用 assign 不起作用，因为它将管道分配给由
%>%使用的临时环境。 如果您确实想对管道使用assign，则必须明确说明环境：env <- environment() "x" %>% assign(100, envir = env) x #> [1] 100
get()和load()函数也存在这样的问题。
-
使用惰性求值的函数。在 R 中，函数参数只在函数使用时计算，而不是在调用函数之前。管道依次计算每个元素，因此您不能依赖此行为。
在使用
tryCatch()是也会出现问题，它可以抓取捕获和处理错误：tryCatch(stop("!"), error = function(e) "An error") #> [1] "An error" stop("!") %>% tryCatch(error = function(e) "An error") #> Error in eval(lhs, parent, parent): !
具有这种行为的函数类相对广泛，包括基R中的try()、suppressMessages()和suppressWarnings()。
3 何时不使用管道
管道是一个强大的工具，但它不是你可以使用的唯一工具，也不能解决所有问题！管道对于重写相当短的线性操作序列最有用。在以下情况下建议使用另一种工具：
你的管道比（比如说）十步长。在这种情况下，创建具有有意义名称的中间对象。这将使调试更容易，因为您可以更轻松地检查中间结果，并且更容易理解代码，因为变量名称可以帮助传达意图。
有多个输入或输出。如果没有变换一个主要对象，而是将两个或多个对象组合在一起，则不要使用管道。
考虑具有复杂依赖结构的有向图。管道基本上是线性的，表达与它们的复杂关系通常会产生令人困惑的代码。
18.4 magrittr 的其他工具
magrittr 包中的其他一些有用工具有哪些呢？
- 当使用更复杂的管道时，有时调用一个函数来处理它的副作用是很有用的。也许您想打印出当前对象，或绘制它，或将其保存到磁盘。很多时候，这样的函数不返回任何东西，有效地终止了管道。
为了解决这个问题，可以使用“tee”管道。%T>%与%>%类似，不同的是%T>%返回左边而不是右边。它被称为“tee”，因为它就像一个字面上的t形管。
rnorm(100) %>%
matrix(ncol = 2) %>%
plot() %>%
str()
#> NULL
rnorm(100) %>%
matrix(ncol = 2) %T>%
plot() %>%
str()
#> num [1:50, 1:2] -0.387 -0.785 -1.057 -0.796 -1.756 ...
-
如果你使用的函数没有基于数据帧的API(例如，你传递给它们单独的向量，而不是一个数据帧和要在该数据帧上下文中计算的表达式)，你可能会发现
%$%很有用。它“展开”数据帧中的变量，可以直接引用它们。这在处理以Base R的许多函数时非常有用:mtcars %$% cor(disp, mpg) #> [1] -0.8475514 -
对于赋值，magrittr提供了
%<>%操作符，它允许你替换如下代码:mtcars <- mtcars %>% transform(cyl = cyl * 2)和
mtcars %<>% transform(cyl = cyl * 2)我不喜欢这个运算符，因为我认为赋值是一种特殊的操作，它在发生时应该总是很清楚。在我看来，一点点重复（即重复两次对象的名称）是可以的，因为可以使分配更加明确。
