leiningenを見よう見まねで動かしはじめてみて、まだ拙くもjavaコードと混合で動かすことを覚えてみたら、今までjavaで書いていたものの多くをclojureで書いてもいいのではないか、そう思うようになりました。もちろん検討選択の上で、適す？適さない？を考えていくなかで、自分のやってきたものはclojure適しているグループが多かったのではないかということを思いました。ただし書くのに適しても総合的に最終的にどうかはまた別問題になってくるかもしれません。しかしながら、実行形式が.class/.jarに落ちてくれるのでどんなソフトウェアでも考えてみる余地があるかと今思っています。*1
clojureが適していると感じた端的な点としては、Threadの扱いについて考えてみたときです。javaのThreadを覚えたときはjava1.4とかで、スレッドを起動したいときは、とにかくjavaのクラス構造に走らせたい処理をrun()メソッドに書くように、となっていて今は無名関数って書き方で省略してできますけども、当時はスレッド処理毎に１クラス増えていく感じでした。*2
javaで書きたくなる場面とは、データ構造なりあるいは抽象層と具体層ががっちり仕様的にも構造化されていてそれを丁寧にインプリメントに落としたいようなとき、そんなときにはclassをきっちり切っていくjavaで書こう書きたくなるのだと思います。*3
gobgp-apiのflowspec処理のため、grpcのスタブ構築をjavaでできること確認出来て、その一例でjavaでgobgpdにflowspec投げる処理を試し書きしてみました。javaのほうを見直してみると、結局javaはこう書かざるを得ない意外にあまりclass構造を取る理由がないんですね。プライベートメンバーにパラメータ生成過程の変数を持つと便利なときもあったり、実際の使い方で同じ処理を繰り返すか流用したりとかの用途によってはオブジェクトとして設計することもありえると思います。
clojureを使う場合にひとつ、データ引き渡し部分が圧倒的に簡潔になると思います。自分的な意図では主に利用者の分かりやすさ観点でjavaの場合はデータメンバ+getter/setterだけのクラス作ること多かったですけども*4、後年は自動生成できるとかもなってますけどもコード量自体が多いとやっぱりデメリットにもなりえます。
今回はflowspecをデモ的に決め打ちで投げるだけ書いてみました。いずれそれに付随して必要であろうgobgp-apiのListPathの呼び出しも考え始めたのですが、このListPathで得られる情報がネストしていたり重複項目があったりでちょっとお試しインプリメントにしても躊躇していたところです。それを今回clojureに？と考えてみるとデータ構造の面、それから処理自体にしてもjavaより*5簡潔にかけてしまいそうです。
今回の場合は、clojureが関数型だから、というよりは、オブジェクト構造にすべて当てはめる必要がないものはある、という理由になると自分は思います。
それと最後に一点、この課題の場合protocの吐くapiの使い方確認のほうが時間かかります。慣れるとそれもclojureのreplからできるのがメリットになりえるかもしれません。
