第20回 #potatotips でJavaのenumについて語ってきた
表題のとおりです．
potatotips #20でLTした
前回（第19回，発表資料）は当日繰り上がり当選，その前（第17回，発表資料）は主催者枠での登壇だったので，正規当選での発表は実は初めてだった．
Effective Java 第2版 (The Java Series)とKeithYokoma氏のQiita記事に自分が最近書いたコードからの知見を加えたもだが， スライドのデザインに気を取られすぎて内容がアレになってしまった．
あと，最近のAndroid界隈の流行に乗ってスライドを英語で作ったらとてもつらいことになった．
トークから漏れたenumの話
スライド後半でenumで実装するイベントハンドラを紹介している．
これはスライドに書いたとおりだけど，大きなメリットとしてはやはりテスタビリティの向上と責務の分散があると思っている．
テスタビリティについては，やはりenumが状態を持たないというのが強い．
入力のみによって出力が決まるという参照透過性ぽい性質を持っているので，テストが全部パラメタライズテストになる．
移譲してきた処理を雑にユニットテストできるようになるので，Viewの状態やらに頭使わなくてよくなる．
責務の分散についてはまあ見ての通りなんだけど，やっぱりswitchとサヨナラできるのうれしい．
break;毎回書き忘れるのに悩まなくてよくなる．テストについても意図通りのhandlerメソッドが呼ばれてることだけ確認できれば問題ない．
あと，null guardとかbreakとか考えずに一行だけ書けば動くのは超便利である．
例ではonClickのハンドリングを出したけど，
BLEのBluetoothGattCharacteristicをUIDDでハンドリングしていくのとかも良い．
ViewのインタラクションとかだとhandlerにView，Activity，Contextあたりを渡さなきゃいけないケースが多くて面倒なんだけど，BLEとかだと雑にEventBusやOtto等のEventEmitter的なやつに乗せて飛ばせば「Viewの実装」「イベントハンドリング」「実際の処理」をほぼ完全に分離できる．
そうなると全体的に疎結合になるし，当然テストも書きやすい．ライブラリやSDKの実装に利用すると捗る．
EventEmitterから連想してObserverパターンやFluxとも相性が良いような気がするからまた試してみたい．
たぶん今週末（8/14）ぐらいにenumまみれになった何かがリリースされますので，マサカリとか投げていだだけると幸いです．
