functionalなアプローチで動的要素を排除する

1. functionalなアプローチで 動的要素を排除する 2024/01/18　東京Ruby会議12 @ryopeko
2. • 関口亮一 • @ryopeko • Backend Engineer
3. 目次 • 動的なアプローチ • Rubyにおける関数型向けの機能 • functionalなアプローチ • ユースケース • 双方の比較 • まとめ
4. 動的なアプローチ
5. Rubyにおける強力な武器のひとつ
6. 動的なアプローチのための機能 • public_send • define_method • etc…
7. メタプログラミング + 動的評価
8. 強力だが強い責任が伴う機能
9. 動的なアプローチのメリットデメリット
10. 動的なアプローチのメリット • 記述量の低減 • 多少の差分を吸収できる • カッコいい • etc…
11. 動的なアプローチのデメリット • 読み解くのに知識が必要 • 実行時になって動作が確定する • grepが効かないケースがある • カッコいい • etc…
12. 動的なあれこれ class Foo %w/a b/.each do |c| define_method ("method_#{c}".to_sym) do # do something end end end
13. 動的なあれこれ public_send(:method_name, "foo")
14. 動的なあれこれ types = ["a", 1] types.each do |type| case type when String public_send(:method_for_string) when Integer public_send(:method_for_integer) else raise ArgumentError end end
15. Rubyにおける関数型向けの機能
16. Rubyにおける関数型向けの機能 • Lambda, Proc • curry (カリー化) • Proc#<<,>>(関数合成) • etc…
17. 関数オブジェクトの生成 lambda {} Proc.new {} -> {}
18. カリー化 f = -> (arg1, arg2) { arg1 + arg2 }.curry(2).call(1) f.call(2) #=> 3
19. 関数合成 f1 = -> (arg1, arg2) { arg1 + arg2 }.curry(2).call(1) f2 = -> (arg3) { arg3.odd? } f = f1 >> f2 f.call(2) #=> true
20. おまけ(method objectもcurry化できる) def method_a(arg1, arg2) # do something end f_method = method(:method_a).curry(2) f_method.call("foo").call("bar")
21. ユースケース
22. 関数型アプローチを使うかどうか考えるポイント • 安易に動的にしようとしてないか一度立 ち止まる • 実行時でないと評価できない？ • 処理 or 定義
23. 定義 or 処理
24. 定義 or 処理 • パイプライン的処理 • 必要なデータが揃っていなくても 一部評価可能な場合(ちょっと説明がムズイ)
25. もう少し具体的な例
26. 少し具体的な例 : 顧客データ import機能 A B C D 1 2 3 4 元データをサービスDBにimportしたいが 変換が必要なケース
27. A B C D 1 2 3 4 rows
28. A B C D 1 2 3 4 rows cols
29. A B C D 1 2 3 4 カラムごとの変換のルールは事前にわかる
30. A B C D 1 2 3 4 行ごとに各々のカラムを変換ルールに 基づき変換していく
31. 定義としての変換ロジックの例
32. 例1: デフォルト値をセットする処理 DEFAULT_VALUE = "foo" f = -> (default_value, value) { value.nil? ? default_value : value }.curry(2).call(DEFAULT_VALUE) f.call(nil) #=> "foo"
33. 例2: 単純な変換をする処理 f = -> (value) { value.upcase } f.call("foo") #=> "FOO"
34. 例3: マッピングを行う処理 RULES = { type1: { conversion: { “FOO” => "HOGE", “BAR” => "FUGA" } } }
35. 例3: マッピングを行う処理 rule = RULES[:type1][:conversion] f = -> (conversion_rule, value) { conversion_rule[value] }.curry(2).call(rule) f.call(“foo”) #=> "hoge"
36. 例4: 1,2,3全ての処理を行う処理 DEFAULT_VALUE = "foo" f1 = -> (default_value, value) { value.empty? ? default_value : value }.curry(2).call(DEFAULT_VALUE)
37. 例4: 1,2,3全ての処理を行う処理 f1 = -> (default_value, value) { value.nil? ? default_value : value }.curry(2).call("foo") f2 = ->(value) { value.upcase } f3 = -> (conversion_rule, value) { conversion_rule[value] }.curry(2).call(rule)
38. 例4: 1,2,3全ての処理を行う処理 f = f1 >> f2 >> f3 f.call(nil) #=> “HOGE”
39. アプローチの比較
40. 動的なアプローチのメリットデメリット
41. 動的なアプローチのメリットデメリット • 記述が少なく繰り返しを排除できる • コードを読むだけでは見通しが立ちにくい • 実行されるまでどう処理されるかわからない • grepが効かないことが多い
42. functionalなアプローチの メリットデメリット
43. functionalなアプローチのメリットデメリット • 処理を定義としてアウトプット可能 • 定義にデータを流すことでテスト可能 • メタプロが発生しないのでgrep可能 • パターンが網羅されていないと記述量で不利にな る場合がある(ただし...)
44. まとめ
45. まとめ • メリットデメリットはどちらにもある • 処理 or 定義でアプローチや表現は変わる • Rubyといえば動的、なわけではない武器はたくさ んある