收集管線

初次接觸

我第一次接觸收集管線模式是在我開始使用 Unix 時。例如，讓我們想像一下我要找到我所有在文字中提到「nosql」的 bliki 條目。我可以使用 grep 來執行此操作

grep -l 'nosql' bliki/entries

我可能想要找出每個條目中包含多少個字詞

grep -l 'nosql' bliki/entries/* | xargs wc -w 

並可能依據字詞數量對它們進行排序

grep -l 'nosql' bliki/entries/* | xargs wc -w | sort -nr

然後僅列印前 3 名（移除總計）

grep -l 'nosql' bliki/entries/* | xargs wc -w | sort -nr | head -4 | tail -3

與我之前（或之後）接觸過的其他命令列環境相比，這項功能非常強大。

稍後，當我開始使用 Smalltalk 時，我發現了相同的模式。假設我有一個文章物件集合（在 someArticles 中），每個物件都有一個標籤集合和一個字詞數量。我可以使用下列方式選取僅具有 #nosql 標籤的文章

 someArticles select: [ :each | each tags includes: #nosql]

select 方法採用單一引數 Lambda（由方括弧定義，在 Smalltalk 中稱為「區塊」），它定義布林函數，並將其套用於 someArticles 中的每個元素，並傳回僅包含 Lambda 解析為 true 的文章集合。

若要對該程式碼的結果進行排序，我會展開程式碼。

(someArticles
      select: [ :each | each tags includes: #nosql]) 
      sortBy: [:a :b | a words > b words]

sortBy 方法是採用 Lambda 的另一種方法，這次是使用來對元素進行排序的程式碼。與 select 類似，它會傳回新的集合，因此我可以繼續執行管線

((someArticles 
      select: [ :each | each tags includes: #nosql])
      sortBy: [:a :b | a words > b words]) 
      copyFrom: 1 to: 3

與 Unix 管線的主要相似之處在於，所涉及的每個方法（select、sortBy 和 copyFrom）都會針對記錄集合進行運算，並傳回記錄集合。在 Unix 中，該集合是串流，其中記錄為串流中的行；在 Smalltalk 中，該集合為物件，但基本概念相同。

現今，我在 Ruby 中進行更多程式設計，其語法讓設定集合管線變得更為容易，因為我不必將管線的早期階段包在括弧中

some_articles
  .select{|a| a.tags.include?(:nosql)}
  .sort_by{|a| a.words}
  .take(3)

在使用物件導向程式語言時，將收集管線形成為方法鏈是一種自然的方法。但相同的概念也可以透過巢狀函式呼叫來完成。

為了回歸一些基礎，讓我們來探討如何在 Common Lisp 中設定類似的管線。我可以將每篇文章儲存在稱為 articles 的結構中，這讓我可以使用像 article-words 和 article-tags 這樣的函式來存取欄位。some-articles 函式會傳回我開始使用的文章。

第一步是只選出 NoSQL 文章。

(remove-if-not
   (lambda (x) (member 'nosql (article-tags x)))
   (some-articles))

與 Smalltalk 和 Ruby 的情況類似，我使用 remove-if-not 函式，它同時接受要操作的清單和定義謂詞的 lambda。然後我可以擴充表達式來排序，再次使用 lambda

(sort
   (remove-if-not
      (lambda (x) (member 'nosql (article-tags x)))
      (some-articles))
   (lambda (a b) (> (article-words a) (article-words b))))

然後我使用 subseq 選擇前 3 名。

(subseq
   (sort
      (remove-if-not
         (lambda (x) (member 'nosql (article-tags x)))
         (some-articles))
      (lambda (a b) (> (article-words a) (article-words b))))
 0 3)

管線就在那裡，你可以看到隨著我們逐步進行，它是如何很好地建立起來的。然而，一旦你查看最終表達式 [1]，就會質疑它的管線性質是否清楚。Unix 管線以及 Smalltalk/Ruby 管線具有與執行順序相符的函式線性排序。你可以輕鬆地將資料視覺化為從左上角開始，然後向右和/或向下通過各種篩選器。Lisp 使用巢狀函式，因此你必須從最深層的函式向上閱讀來解析順序。

最近流行的 Lisp，Clojure，避免了這個問題，讓我可以像這樣編寫它。

(->> (articles)
     (filter #(some #{:nosql} (:tags %)))
     (sort-by :words >)
     (take 3))

「->>」符號是一個執行緒巨集，它使用 Lisp 強大的語法巨集功能將每個表達式的結果執行緒到下一個表達式的引數中。只要你在函式庫中遵循慣例（例如讓主旨收集成為每個轉換函式中的最後一個引數），就可以使用它將一系列巢狀函式轉換為線性管線。

然而，對於許多函式程式設計人員來說，使用這種線性方法並非重要的事情。這些程式設計人員可以很好地處理巢狀函式的深度排序，這就是為什麼像「->>」這樣的運算子花費這麼長時間才成為流行的 Lisp 的原因。

這些天我經常聽到函式程式設計的愛好者讚揚收集管線的優點，說它們是 OO 語言所缺乏的函式語言的強大功能。作為一個老 Smalltalker，我發現這相當令人討厭，因為 Smalltalker 廣泛地使用它們。人們說收集管線不是 OO 程式設計功能的原因是，像 C++、Java 和 C# 等流行的 OO 語言沒有採用 Smalltalk 使用 lambda，因此沒有支援收集管線模式的豐富收集方法陣列。因此，收集管線對大多數 OO 程式設計人員來說已經消失了。像我這樣的 Smalltalker 在 Java 成為城鎮中的大事時詛咒缺乏 lambda，但我們必須忍受它。有各種嘗試使用我們在 Java 中可以使用的東西來建立收集管線；畢竟，對於 OOer 來說，函式只是一個具有單一方法的類別。但產生的程式碼非常混亂，即使是熟悉這項技術的人也傾向於放棄。Ruby 對收集管線的舒適支援是我在 2000 年左右開始大量使用 Ruby 的主要原因之一。我從 Smalltalk 時代就非常想念那樣的東西。

現今，Lambda 已擺脫許多進階且難以使用的語言功能的惡名。在主流語言中，C# 已使用它們好幾年，甚至 Java 也終於加入。 [2] 因此，現在許多語言都可以使用集合管線。

定義收集管線

我認為集合管線是一種模組化和組合軟體的模式。像大多數模式一樣，它會出現在許多地方，但每次出現時表面上看起來都不同。不過，如果你了解底層模式，就能輕鬆找出在新的環境中想做的事。

集合管線會規劃一連串的運算，這些運算會在它們之間傳遞一個項目集合。每個運算會將集合視為輸入，並發出另一個集合（最後一個運算除外，它可能是發出單一值的終端）。個別運算很簡單，但你可以將各種運算串接在一起，就能創造出複雜的行為，就像你可能會在物理世界中將管道連接在一起一樣，因此有了管線的比喻。

集合管線是 Pipes and Filters 模式 的特例。Pipes and Filters 中的篩選器對應到集合管線中的運算，我將「篩選器」替換為運算，因為篩選器是集合管線中一種運算的常見名稱。從另一個角度來看，集合管線是組合高階函式的特定但常見情況，其中函式都作用於某種形式的序列資料結構。這個模式沒有既定的名稱，所以我認為有必要訴諸 新創詞。

運算和在運算之間傳遞的集合會在不同的脈絡中採用不同的形式。

在 Unix 中，集合是一個文字檔，其項目是檔中的行。每行包含各種值，以空白字元分隔。每個值的意義由它在行中的順序決定。運算是 Unix 程序，集合則使用管線運算子組合，其中一個程序的標準輸出會導管到下一個程序的標準輸入。

在物件導向程式中，集合是一個集合類別（清單、陣列、集合等）。集合中的項目是集合內的物件，這些物件本身可能是集合或包含更多集合。運算是集合類別本身定義的各種方法，通常在某個高階超類別上。運算是透過方法鏈組合的。

在函式語言中，集合以類似於物件導向語言的方式成為集合。不過，這次的項目本身是泛型集合類型，其中物件導向集合管線會使用物件，函式語言會使用雜湊映射。頂層集合的元素本身可能是集合，雜湊映射的元素也可能是集合，因此就像物件導向的情況一樣，我們可以擁有任意複雜的階層結構。運算是函式，它們可以透過巢狀或運算子組合，例如 Clojure 的箭頭運算子，形成線性表示。

這個模式也會出現在其他地方。當關係模型首次定義時，它附帶了一個 關係代數，你可以將它視為一個集合管線，其中中間集合受到約束，必須是關係。但 SQL 沒有使用管線方法，而是使用類似於理解的方法（我稍後會討論）。

一系列此類轉換的概念是建構程式的一種常見方法 - 因此收集管道和篩選器架構模式。編譯器通常以這種方式運作，從原始碼轉換為語法樹，經過各種最佳化，然後輸出程式碼。收集管道的不同之處在於，各階段之間的共同資料結構是一個集合，這會導致一組特定的常見管道操作。

探索更多管線和操作

到目前為止，我使用過的一個範例管道只使用了收集管道中常見的幾個操作。因此，現在我將使用幾個範例來探討更多操作。我將堅持使用 Ruby，因為我最近比較熟悉這門語言，但通常可以在支援此模式的其他語言中形成相同的管道。

- title: NoDBA
  words: 561
  tags: [nosql, people, orm]
  type: :bliki
- title: Infodeck
  words: 1145
  tags: [nosql, writing]
  type: :bliki
- title: OrmHate
  words: 1718
  tags: [nosql, orm]
  type: :bliki
- title: ruby
  words: 1313
  tags: [ruby]
  type: :article
- title: DDD_Aggregate
  words: 482
  tags: [nosql, ddd]
  type: :bliki

5219

[1, 2, 3].map{|i| i * i} # => [1, 4, 9]

[1, 2, 3].reduce {|acc, each| acc + each} # => 6

some_articles
  .map{|a| a.words}
  .reduce {|acc, w| acc + w}

(->> (articles)
     (map :words)
     (reduce +))

some_articles
  .map(&:words)
  .reduce(:+)

- title: NoDBA
  words: 561
  tags: [nosql, people, orm]
  type: :bliki
- title: Infodeck
  words: 1145
  tags: [nosql, writing]
  type: :bliki
- title: OrmHate
  words: 1718
  tags: [nosql, orm]
  type: :bliki
- title: ruby
  words: 1313
  tags: [ruby]
  type: :article
- title: DDD_Aggregate
  words: 482
  tags: [nosql, ddd]
  type: :bliki

{bliki: 4, article: 1}

some_articles
  .group_by {|a| a.type}

some_articles
  .group_by {|a| a.type}
  .map {|pair| [pair[0], pair[1].size]}
  .to_h

some_articles
  .group_by {|a| a.type}
  .map {|key, value| [key, value.size ]}
  .to_h

(->> (articles)
     (group-by :type)
     (map (fn [[k v]] [k (count v)]))
     (into {}))

- title: NoDBA
  words: 561
  tags: [nosql, people, orm]
  type: :bliki
- title: Infodeck
  words: 1145
  tags: [nosql, writing]
  type: :bliki
- title: OrmHate
  words: 1718
  tags: [nosql, orm]
  type: :bliki
- title: ruby
  words: 1313
  tags: [ruby]
  type: :article
- title: DDD_Aggregate
  words: 482
  tags: [nosql, ddd]
  type: :bliki

:nosql:
  :articles: 4
  :words: 3906
:people:
  :articles: 1
  :words: 561
:orm:
  :articles: 2
  :words: 2279
:writing:
  :articles: 1
  :words: 1145
:ruby:
  :articles: 1
  :words: 1313
:ddd:
  :articles: 1
  :words: 482

some_articles
  .map {|a| a.tags.map{|tag| [tag, a]}}   

[
  [ [:nosql, Article(NoDBA)]
    [:people, Article(NoDBA)]
    [:orm, Article(NoDBA)]
  ]
  [ [:nosql, Article(Infodeck)]
    [:writing, Article(Infodeck)]
  ]
  # more rows of articles
]

some_articles
  .map {|a| a.tags.map{|tag| [tag, a]}}   
  .flatten 1

[
  [:nosql, Article(NoDBA)]
  [:people, Article(NoDBA)]
  [:orm, Article(NoDBA)]
  [:nosql, Article(Infodeck)]
  [:writing, Article(Infodeck)]
  # more rows of articles
]

some_articles
  .flat_map {|a| a.tags.map{|tag| [tag, a]}}    

some_articles
  .flat_map {|a| a.tags.map{|tag| [tag, a]}}
  .group_by {|pair| pair.first}

{
  :people:
    [ [:people, Article(NoDBA)] ]
  :orm:
    [ [:orm, Article(NoDBA)]
      [:orm, Article(OrmHate)]
    ]
  :writing:
    [  [:writing, Article(Infodeck)] ]
  # more records
}

some_articles
  .flat_map {|a| a.tags.map{|tag| [tag, a]}}
  .group_by {|pair| pair.first}
  .map {|k,pairs| [k, pairs.map {|p| p.last}]}        

{
  :people:    [ Article(NoDBA) ]
  :orm:       [ Article(NoDBA), Article(OrmHate) ]
  :writing:   [ Article(Infodeck) ]
  # more records
}

some_articles
  .flat_map {|a| a.tags.map{|tag| [tag, a]}}
  .group_by {|pair| pair.first}
  .map {|k,pairs| [k, pairs.map {|p| p.last}]}    
  .map {|k,v| [k, {articles: v.size, words: v.map(&:words).reduce(:+)}]}
  .to_h

:nosql:
  :articles: 4
  :words: 3906
:people:
  :articles: 1
  :words: 561
:orm:
  :articles: 2
  :words: 2279
:writing:
  :articles: 1
  :words: 1145
:ruby:
  :articles: 1
  :words: 1313
:ddd:
  :articles: 1
  :words: 482

(->> (articles)
     (mapcat #(map (fn [tag] [tag %]) (:tags %)))
     (group-by first)
     (map (fn [[k v]] [k (map last v)]))
     (map (fn [[k v]] {k {:articles (count v), :words (reduce + (map :words v))}}))
     (into {}))

(defn index-by [f, seq]
    (->> seq
         (mapcat #(map (fn [key] [key %]) (f %)))
         (group-by first)
         (map (fn [[k v]] [k (map last v)]))))
(defn total-words [articles] 
    (reduce + (map :words articles)))
  
(->> (articles)
     (index-by :tags)
     (map (fn [[k v]] {k {:articles (count v), :words (total-words v)}}))
     (into {}))

class Array
  def invert_index_by &proc
    flat_map {|e| proc.call(e).map {|key| [key, e]}}
      .group_by {|pair| pair.first}
      .map {|k,pairs| [k, pairs.map {|p| p.last}]}         
  end
end

total_words = -> (a) {a.map(&:words).reduce(:+)}
some_articles
  .invert_index_by {|a| a.tags}   
  .map {|k,v| [k, {articles: v.size, words: total_words.call(v)}]}
  .to_h

class ArticleSummary
  def initialize articles
    @articles = articles
  end
  def size
    @articles.size
  end
  def total_words
    @articles.map{|a| a.words}.reduce(:+)
  end
end

some_articles
  .invert_index_by {|a| a.tags}   
  .map {|k,v| [k, ArticleSummary.new(v)]}
  .map {|k,a| [k, {articles: a.size, words: a.total_words}]}
  .to_h

替代方案

集合管線模式並非達成我到目前為止所討論類型事物的唯一方式。最明顯的替代方案是大多數人通常會在這些案例中使用的：簡單迴圈。

some_articles
  .select{|a| a.tags.include?(:nosql)}
  .sort_by{|a| a.words}
  .take(3)

result = []
some_articles.each do |a|
  result << a if a.tags.include?(:nosql)   
end
result.sort_by!(&:words)
return result[0..2]

some_articles
  .map{|a| a.words}
  .reduce {|acc, w| acc + w}

result = 0
some_articles.each do |a|
  result += a.words
end
return result

some_articles
  .group_by {|a| a.type}
  .map {|pair| [pair[0], pair[1].size]}
  .to_h

result = Hash.new(0)
some_articles.each do |a|
  result[a.type] += 1
end
return result

some_articles
  .flat_map {|a| a.tags.map{|tag| [tag, a]}}
  .group_by {|pair| pair.first}
  .map {|k,pairs| [k, pairs.map {|p| p.last}]}    
  .map {|k,v| [k, {articles: v.size, words: v.map(&:words).reduce(:+)}]}
  .to_h

result = Hash.new([])
some_articles.each do |a|
  a.tags.each do |t|
    result[t] += [a]
  end
end
result.each do |k,v|
  word_count = 0
  v.each do |a|
    word_count += a.words
  end
  result[k] = {articles: v.size, words: word_count}
end
return result

some_articles
  .filter (a) ->
    a.words > 1000
  .map (a) ->
    a.title

(a.title for a in some_articles when a.words > 1000)

some_articles
  .filter (a) ->
    a.words > 1000
  .map (a) ->
    a.words
  .reduce (x, y) -> x + y

(a.words for a in some_articles when a.words > 1000)
.reduce (x, y) -> x + y

接下來的問題是，對於它們適用的案例，理解是否優於管線。理解的愛好者表示是，其他人可能表示管線一樣容易理解且更通用。（我屬於後者。）

巢狀運算子表達式

你可以使用收集執行的有用事情之一是使用集合運算來操作它們。因此，假設我正在查看一家飯店，其功能是傳回紅、藍、在飯店前面或已入住的房間。然後，我可以使用表達式找出飯店前面未入住的紅色或藍色房間。

(front & (red | blue)) - occupied

(difference
 (intersection
  (union reds blues)
  fronts)
 occ)

Clojure 定義其集合資料類型上的集合運算，因此這裡的所有符號都是集合。

我可以將這些表達式制定為收集管線

red
  .union(blue)
  .intersect(front)
  .diff(occupied)

我猴子修補程式 Array 以將集合運算新增為常規方法

(->> reds
     (union blues)
     (intersection fronts)
     (remove occ))

我需要 clojure 的「移除」方法才能按正確順序取得執行緒參數。

但我比較偏好 巢狀運算式表達式 形式，特別是在我可以使用中綴運算子時。而且較複雜的表達式可能會變成像管道一樣糾纏不清。

話雖如此，在管道中間插入集合運算通常很有用。讓我們想像一個案例，其中房間的顏色和位置是房間記錄的屬性，但已佔用的房間清單在一個獨立的集合中。

rooms
  .select{|r| [:red, :blue].include? r.color}
  .select{|r| :front == r.location}
  .diff(occupied)

(->> (rooms)
     (filter #( #{:blue :red} (:color %)))
     (filter #( #{:front} (:location %)))
     (remove (set (occupied))))

這裡我顯示 (set (occupied)) 來展示我們如何使用包覆在集合上的集合作為 Clojure 中集合成員資格的謂詞。

雖然中綴運算子適用於巢狀運算式表達式，但它們不適用於管道，這會強迫使用一些惱人的括號。

((rooms
  .select{|r| [:red, :blue].include? r.color}
  .select{|r| :front == r.location}
  ) - occupied)
  .map(&:num)
  .sort

使用集合運算時，要注意的另一點是集合通常是有序且允許重複的清單。你必須查看函式庫的特定部分，才能了解集合運算的意義。Clojure 強制你在對集合使用集合運算之前將它們轉換為集合。Ruby 會接受任何陣列作為其集合運算子，但會移除輸出中的重複項，同時保留輸入順序。

惰性

惰性化的概念來自函式程式設計的世界。動機可能是像這樣的程式碼

large_list
  .map{|e| slow_complex_method (e)}
  .take(5)

使用這樣的程式碼，你會花很多時間在許多元素上評估 slow_complex_method，然後丟棄所有結果，只留下前 5 個。惰性化允許底層平台確定你只需要前 5 個結果，然後只對需要的結果執行 slow_complex_method。

事實上，這進一步深入執行時間使用，讓我們想像 slow_complex_method 的結果被傳輸到 UI 上的捲動清單中。惰性管道只會在最終結果捲動到視圖中時，才在元素上呼叫管道。

要讓集合管道變為惰性，集合管道函式必須以惰性化為考量來建構。一些語言，通常是像 Clojure 和 Haskell 這樣的函式語言，從一開始就這樣做。在其他情況下，惰性化可以建構到集合類別的特殊群組中 - Java 和 Ruby 有一些惰性集合實作。

有些管線操作無法與惰性運算搭配使用，必須評估整個清單。排序就是一個範例，沒有整個清單，你甚至無法決定單一最高值。重視惰性運算的平台通常會記錄無法保留惰性運算的操作。

平行處理

許多管線操作自然很適合並行呼叫。如果我使用 map，將它用於一個元素的結果不會依賴於集合中的任何其他元素。因此，如果我在具有多個核心的平台上執行，我可以透過將 map 評估分配到多個執行緒來利用這一點。

許多平台包含以這種方式並行分配評估的能力。如果你對大型集合執行複雜函數，透過利用多核心處理器，這可能會帶來顯著的效能提升。

然而，並行化並不總是會提升效能。有時候，設定並行分配所需的時間比從並行化獲得的收益還多。因此，大多數平台提供明確使用並行化的替代操作，例如 Clojure 的 pmap 函數是 map 的並行版本。與任何效能最佳化一樣，你應該使用效能測試來驗證使用並行化操作是否實際提供任何效能改善。

不可變性

集合管線自然而然地適用於不可變資料結構。在建立管線時，將每個操作視為為其輸出產生新集合是很自然的。天真地這麼做會涉及大量複製，這可能會導致大量資料的問題。然而，大多數時候，這在實務上並非問題。通常，複製的資料指標集較小，而不是大量資料。

當它確實成為問題時，你可以透過設計成以這種方式轉換的資料結構來保留不可變性。函式程式語言傾向於使用資料結構，可以有效地以這種樣式進行處理。

如有必要，你可以透過使用更新集合而不是取代集合的操作來犧牲可變性。非函式語言中的函式庫通常提供集合管線運算子的破壞性版本。我強烈建議你僅將它們用於 有紀律的效能調整練習 的一部分。開始使用非變異操作，只有在管線中遇到已知的效能瓶頸時才使用其他方法。

除錯

對於除錯集合管線的難度，我收到幾個問題。考慮類似於 ruby 中的這個管線

def get_readers_of_books1(readers, books, date)
  data = @data_service.get_books_read_on(date)
  return data
    .select{|k,v| readers.include?(k)}
    .select{|k,v| !(books & v).empty?}
    .keys
end

現代 IDE 可以提供很多除錯協助，但讓我們想像我在 ruby 中執行這項工作，僅使用 emacs，而且我嘲笑除錯器。

我可能想要在管道中程中提取一個中間變數

def get_readers_of_books2(readers, books, date)
  data = @data_service.get_books_read_on(date)
  temp = data
    .select{|k,v| readers.include?(k)}
    .select{|k,v| !(books & v).empty?}
  pp temp
  return temp
    .keys
end

另一件有點棘手的事情是將列印陳述句偷渡到管道中的映射中。

def get_readers_of_books(readers, books, date)
  data = @data_service.get_books_read_on(date)
  return data
    .select{|k,v| readers.include?(k)}
    .select{|k,v| !(books & v).empty?}
    .map {|e| pp e; e}.to_h
    .keys
end

在這種情況下，我需要在映射操作後轉換回雜湊

這確實需要在管道內部產生一些副作用，如果它逃脫到程式碼檢閱中，你應該會被告知，但它可以幫助視覺化程式碼在做什麼。

使用適當的偵錯程式，你通常可以在偵錯程式中評估表達式。這樣，你可以在管道中設定中斷點，然後根據管道的部分評估表達式，以查看正在發生什麼事。

何時使用

我將集合管道視為一種模式，而對於任何模式，都有你應該使用它的時候，也有你應該採取其他途徑的時候。如果我無法想到不使用我喜歡的模式的原因，我總是會產生懷疑。

避免它的第一個跡象是當語言支援不存在時。當我開始使用 Java 時，我錯過了大量使用集合管道的機會，所以像許多其他人一樣，我嘗試製作可以形成模式的物件。你可以透過建立類別和使用匿名內部類別等方法來形成管道操作，以接近 lambda。但問題在於語法太過混亂，淹沒了使集合管道如此有效的清晰度。所以我放棄了，改用迴圈。從那時起，各種函式式樣式的函式庫出現在 Java 中，其中許多使用註解，這些註解在早期並不存在於語言中。但我的感覺仍然是，如果沒有對乾淨 lambda 表達式的良好語言支援，這種模式通常最終會帶來比其價值更多的麻煩。

另一個反對的論點是當你具有理解時。在這種情況下，理解通常更容易用於簡單表達式，但你仍然需要管道才能獲得更大的靈活性。就我個人而言，我發現簡單的管道與理解一樣容易理解，但這是一個團隊必須在其編碼風格中決定的類型。

即使在適用的語言中，您也會遇到不同的限制 - 管道的規模和複雜性。我在這篇文章中展示的管道很小而且是線性的。我的習慣是撰寫小函式，如果它們超過半打行，我便會感到緊張，管道也有類似的規則。較大的管道需要分解成不同的方法，遵循我的一貫規則：只要程式碼區塊的運作方式與執行方式不同，就萃取一個方法。

當管道是線性的時，它們的效果最佳，每個步驟都有單一集合輸入和單一輸出。可以分岔到不同的輸入和輸出，儘管我在這篇文章中沒有提供任何這樣的範例。不過，請再次注意這一點 - 分解成不同的函式通常是控制較長行為的關鍵。

話雖如此，集合管道是一個很棒的模式，所有程式設計師都應該了解，特別是在像 Ruby 和 Clojure 這樣支援它們的語言中。它們可以清楚地擷取原本需要冗長且複雜的迴圈，並有助於讓程式碼更具可讀性，從而降低成本並更容易增強。