コレクションパイプライン

最初の出会い

私がコレクションパイプラインパターンに初めて出会ったのは、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メソッドは、単一の引数ラムダ（角括弧で定義され、smalltalkでは「ブロック」と呼ばれます）を受け取ります。これは、someArticlesのすべての要素に適用されるブール関数を定義し、ラムダがtrueと評価される記事のみのコレクションを返します。

そのコードの結果をソートするには、コードを展開します。

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

sortByメソッドは、ラムダを受け取る別のメソッドです。今回は、要素をソートするために使用されるコードです。 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でプログラミングを行うことが多くなっています。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を使用します。その後、式を展開してソートすることができます。ここでもラムダを使用します。

(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に登場するまでには、非常に長い時間がかかりました。

最近では、関数型プログラミングのファンがコレクションパイプラインの利点を称賛し、オブジェクト指向言語にはない関数型言語の強力な機能であると述べているのをよく耳にします。古くからのSmalltalkerとして、これはSmalltalkerがそれらを広く使用していたため、いささか迷惑に感じます。人々がコレクションパイプラインはオブジェクト指向プログラミングの機能ではないと言う理由は、C++、Java、C＃のような一般的なオブジェクト指向言語がSmalltalkのラムダの使用を採用せず、したがってコレクションパイプラインパターンの基礎となる豊富なコレクションメソッドを持っていなかったためです。その結果、ほとんどのオブジェクト指向プログラマーにとってコレクションパイプラインは消滅しました。私のようなSmalltalkerは、Javaが大きな話題になったときにラムダがないことを呪いましたが、私たちはそれで我慢しなければなりませんでした。Javaでできることを使ってコレクションパイプラインを構築しようとする試みはさまざまありました。結局のところ、オブジェクト指向プログラマーにとって、関数は1つのメソッドを持つクラスにすぎません。しかし、結果のコードは非常に厄介だったため、この手法に精通している人でさえ諦める傾向がありました。 Rubyのコレクションパイプラインの快適なサポートは、2000年頃にRubyを本格的に使い始めた主な理由の1つでした。Smalltalk時代からそのようなものがたくさん恋しかったです。

最近では、ラムダは高度で使いにくい言語機能であるという評判をかなり払拭しています。主流言語のC＃は、それらを数年間使用しており、ついにJavaも参加しました。 [2]そのため、現在、コレクションパイプラインは多くの言語で実行可能です。

コレクションパイプラインの定義

コレクションパイプラインは、ソフトウェアをモジュール化および構成する方法のパターンであると考えています。ほとんどのパターンと同様に、多くの場所で発生しますが、表面上は異なって見えます。ただし、基礎となるパターンを理解していれば、新しい環境で何をしたいかを簡単に理解できます。

コレクションパイプラインは、項目のコレクションをそれらの間で渡す一連の操作をレイアウトします。各操作は、コレクションを入力として受け取り、別のコレクションを出力します（最後の操作を除く。最後の操作は、単一の値を出力する端末である場合があります）。個々の操作は単純ですが、物理的世界でパイプを接続するのと同じように、さまざまな操作を連結することによって複雑な動作を作成できます。そのため、パイプラインのメタファーが使用されます。

コレクションパイプラインは、パイプとフィルターパターンの特殊なケースですが、一般的なケースです。パイプとフィルターのフィルターはコレクションパイプラインの操作に対応し、「フィルター」を操作に置き換えます。これは、フィルターがコレクションパイプラインの種類の操作の1つの一般的な名前であるためです。別の観点から見ると、コレクションパイプラインは、高階関数を構成する特定の、しかし一般的なケースであり、関数はすべて何らかの形式のシーケンスデータ構造で動作します。このパターンには確立された名前がないため、新語に頼る必要があると感じました。

操作と操作間で渡されるコレクションは、さまざまなコンテキストで異なる形式を取ります。

Unixでは、コレクションはテキストファイルであり、その項目はファイル内の行です。各行には、空白で区切られたさまざまな値が含まれています。各値の意味は、行内の順序によって決まります。操作はunixプロセスであり、コレクションはパイプライン演算子を使用して構成され、1つのプロセスの標準出力が次のプロセスの標準入力にパイプされます。

オブジェクト指向プログラムでは、コレクションはコレクションクラス（リスト、配列、セットなど）です。コレクション内の項目はコレクション内のオブジェクトであり、これらのオブジェクトはコレクション自体であるか、より多くのコレクションを含む場合があります。操作は、コレクションクラス自体に定義されたさまざまなメソッドです。通常は、ある高レベルのスーパー クラスにあります。操作はメソッドチェーンを介して構成されます。

関数型言語では、オブジェクト指向言語と同様にコレクションが扱われます。しかし、今回は項目がジェネリックなコレクション型自身である点が異なります。オブジェクト指向のコレクションパイプラインではオブジェクトを使用するのに対し、関数型言語ではハッシュマップを使用します。最上位コレクションの要素はコレクション自身である可能性があり、ハッシュマップの要素もコレクションである可能性があります。そのため、オブジェクト指向の場合と同様に、任意の複雑な階層構造を持つことができます。操作は関数であり、ネストによって、またはClojureの矢印演算子など、線形表現を形成できる演算子によって構成できます。

このパターンは他の場所にも現れます。リレーショナルモデルが最初に定義されたとき、中間コレクションがリレーションに制約されているコレクションパイプラインと考えることができる関係代数が付属していました。しかし、SQLはパイプラインアプローチを使用せず、代わりに内包表記（後で説明します）のようなアプローチを使用します。

このように一連の変換という概念は、プログラムを構造化する一般的なアプローチです。そのため、パイプとフィルタのアーキテクチャパターンが活用されています。コンパイラは、ソースコードから構文ツリー、さまざまな最適化を経て出力コードに変換する際に、この方法で動作することがよくあります。コレクションパイプラインの特徴は、ステージ間の共通データ構造がコレクションであることであり、特定の共通パイプライン操作につながります。

より多くのパイプラインと操作の探求

これまでに使用したパイプラインの例では、コレクションパイプラインで一般的な操作をいくつか使用しています。そこで、いくつかの例を使用して、より多くの操作を調べていきます。最近はRubyに慣れてきているので、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

問題は、内包表記が機能するケースでは、パイプラインよりも優れているかどうかです。内包表記のファンは優れていると言い、パイプラインは理解しやすく、より一般的であると言う人もいます。（私は後者のグループに属します。）

ネストされた演算子式

コレクションでできる便利なことの1つは、集合演算で操作することです。赤い部屋、青い部屋、ホテルの正面にある部屋、または占有されている部屋を返す関数を持つホテルを考えてみましょう。式を使用して、ホテルの正面にある空いている赤または青の部屋を見つけることができます。

(front & (red | blue)) - occupied

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

Clojureは集合データ型に集合演算を定義しているため、ここでのすべての記号は集合です。

これらの式をコレクションパイプラインとして formulation することができます

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

集合演算を通常のメソッドとして追加するために、Arrayをモンキーパッチしました。

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

スレッディングのために引数を正しい順序で取得するには、clojureの「remove」メソッドが必要です。

しかし、私は入れ子になった演算子式形式、特に中置演算子を使用できる場合は、そちらを好みます。また、より複雑な式はパイプとして非常に複雑になる可能性があります。

とはいえ、パイプラインの途中で集合演算を投入すると便利なことがよくあります。部屋の色と場所は部屋レコードの属性ですが、占有されている部屋のリストは別のコレクションにある場合を考えてみましょう。

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

集合演算に関して覚えておくべきもう1つのポイントは、コレクションは通常、順序付けられ、重複が許可されるリストであるということです。集合演算にとってそれが何を意味するのかを知るには、ライブラリの詳細を確認する必要があります。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には、遅延コレクションの実装がいくつかあります。

一部のパイプライン操作は遅延では機能せず、リスト全体を評価する必要があります。ソートはその一例であり、リスト全体がないと、1つの上位値さえ決定できません。遅延を真剣に受け止めているプラットフォームは、通常、遅延を維持できない操作を文書化します。

並列処理

多くのパイプライン操作は、並列呼び出しで自然にうまく機能します。map を使用する場合、1つの要素に使用した結果は、コレクション内の他の要素に依存しません。そのため、複数のコアを持つプラットフォームで実行している場合は、マップ評価を複数のスレッドに分散することで、その利点を利用できます。

多くのプラットフォームには、このように並列に評価を分散する機能が含まれています。大規模な集合に対して複雑な関数を実行している場合、マルチコアプロセッサを活用することで、パフォーマンスが大幅に向上する可能性があります。

ただし、並列化は必ずしもパフォーマンスを向上させるわけではありません。並列処理によるメリットよりも、並列分散のセットアップに時間がかかる場合があります。その結果、ほとんどのプラットフォームでは、並列処理を明示的に使用する代替操作を提供しています。たとえば、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

もう1つの、ややトリッキーなことは、パイプラインのマップにprintステートメントを密輸することです。

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

この場合、マップ操作後にハッシュに変換し直す必要があります

これには、パイプライン内にいくつかの副作用が必要です。コードレビューにエスケープした場合、叱責される可能性がありますが、コードの動作を視覚化するのに役立ちます。

適切なデバッガを使用すると、通常、デバッガで式を評価できます。このようにして、パイプにブレークポイントを設定し、パイプの一部に基づいて式を評価して、何が起こっているかを確認します。

いつ使用するか

コレクションパイプラインを1つのパターンとして捉えています。どのパターンにも言えることですが、使うべき時と、別の方法を取るべき時があります。自分が好きなパターンを使わない理由を思いつかない時は、常に疑念を抱きます。

避けるべき最初の兆候は、言語によるサポートがない場合です。Javaを使い始めた頃は、コレクションパイプラインを使えないことを非常に残念に思っていたので、他の人たちと同じように、このパターンを形成できるオブジェクトの作成を試しました。クラスを作成し、ラムダ式に近づけるために匿名内部クラスのようなものを使用することで、パイプライン操作を形成できます。しかし、問題は構文があまりにも煩雑で、コレクションパイプラインを効果的にする明瞭さを損なってしまうことです。そこで私は諦めて、代わりにループを使用しました。それ以来、Javaにはさまざまな関数型スタイルのライブラリが登場し、その多くは初期の頃には言語に存在しなかったアノテーションを使用しています。しかし、クリーンなラムダ式を適切にサポートする言語機能がなければ、このパターンは結局、手間がかかるだけでメリットがないというのが私の感想です。

反対するもう1つの議論は、内包表記がある場合です。その場合、単純な式では内包表記の方が扱いやすいことが多いですが、より柔軟性を高めるためには、依然としてパイプラインが必要です。個人的には、単純なパイプラインは内包表記と同じくらい理解しやすいと思いますが、それはチームがコーディングスタイルで決定すべきことです。

適切な言語であっても、別の制限、つまりパイプラインのサイズと複雑さに直面することがあります。この記事で示したものは、小さく直線的なものです。私は一般的に小さな関数を書く習慣があり、6行を超えると落ち着かなくなりますが、パイプラインにも同様のルールがあります。大きなパイプラインは、私の通常のルールに従って、個別のメソッドに分割する必要があります。コードブロックの何をするかとどのようにするかに違いがある場合は常にメソッドを抽出します。

パイプラインは、各ステップに単一のコレクション入力と単一の出力がある直線的な場合に最適に機能します。この記事ではそのような例を挙げていませんが、別々の入力と出力に分岐することも可能です。しかし、これも注意が必要です。個別の関数に分割することが、長い動作を制御するための鍵となることがほとんどです。

とはいえ、コレクションパイプラインは優れたパターンであり、すべてのプログラマーが知っておくべきものです。特にRubyやClojureのように、このパターンをうまくサポートしている言語ではそうです。コレクションパイプラインは、そうでなければ長く複雑なループが必要となるものを明確に捉えることができ、コードを読みやすくし、ひいてはコストを削減し、拡張を容易にすることができます。