フィルトウィズ：ナンバーワンくじ、マジカルクッキングをRangeTableで表す

[ochaochaocha3]

フィルトウィズの #311 と被らない範囲のリファクタリングです。ナンバーワンくじとマジカルクッキングの表をRangeTableで表しました。その際、本体のファイルが約1500行と非常に長かったため、別ファイルに分けました。取り出した項目によって他の表を再度引くという処理が同じだったため、roll_jump_table というメソッドを作って共通化しました。

[codecov]

Codecov Report

Merging #324 (f1b73e9) into master (ee47c24) will increase coverage by 0.14%.
The diff coverage is 96.00%.

@@            Coverage Diff             @@
##           master     #324      +/-   ##
==========================================
+ Coverage   93.38%   93.53%   +0.14%     
==========================================
  Files         255      257       +2     
  Lines       18358    18318      -40     
==========================================
- Hits        17143    17133      -10     
+ Misses       1215     1185      -30     

Impacted Files	Coverage Δ
lib/bcdice/game_system/FilledWith.rb	64.51% <94.44%> (+1.55%)	⬆️
lib/bcdice/game_system/filled_with/lot_tables.rb	94.73% <94.73%> (ø)
lib/bcdice/game_system/filled_with/cook_tables.rb	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ee47c24...f1b73e9. Read the comment docs.

[ysakasin]

RangeTableを流用するのではなく、この件用にクラスを作ってしまうのが王道かと思うのですが、それだとやりづらいでしょうか？

[ochaochaocha3]

当初新しいクラスを作りかけ、最終的にRangeTableと関数1つになりクラスにするまでもないように感じたのでこれに落ち着きました。クラスにする場合、どのデータをメンバとして持たせるのを想定しているでしょうか？

[ysakasin]

メンバ粒度は現在と同じ程度のものを考えていました。
ファイル分割というメインの目的は果たしているので大丈夫そうですね。

[ysakasin]

ただ、lamdaでわざわざ遅延評価しているのは結構トリッキーかとも思うので、より良い方法が思いついたらあとでリファクタリングお願いします。

[ochaochaocha3]

lambda での遅延評価はもともと入っていまして、当初はできれば避けようとしていたのですが、簡潔さの面でこれに落ち着いてしまいました。lambda を避けるとなると、次に引く表とレベルを保持する配列/構造体あたりが必要なのですが、書く場所の都合上、表の名前をそのまま書くのが難しかった（未定義で NameError になりやすかった）です。一旦文字列やSymbolに変えると、どこかで分岐を別に書かなければならず長くなりそうでした。