http://lcfactory.doorkeeper.jp/events/2719
2013/02/23 オブジェクト設計エクササイズ #lcfactory
http://togetter.com/li/467691
はじめに
以前に、「学び方を学ぶ 〜オブジェクト指向の設計と実装を学ぶ〜に参加してきました。 #devlove」で講師をされた増田さん(@masuda220)がオブジェクト指向設計についての勉強会をされるということでしたので、申し込みました。
エクササイズ
今回は、オブジェクト設計エクササイズということで、以下のルールについての説明がありました。
オブジェクトを小さくバラバラにする理由は、隣同士の繋がりだけに落としこむことで全体を知らなくてもうまく動かせるようにするためということです。
こうすることでテストを行う際もモックで置き換えることが出来るので対象範囲を狭くすることが出来るのではないかなと感じました。
小さくするということで重要になってくるのは、オブジェクトにどのように名前をつければ、バラバラになっても分かりやすくなるのかということだと思います。
そのためには、省略せず対象分野の言葉を使うのが一番です。
英語で名前をつけるのが殆どなのですが、辞書を引いたままの言葉よりも同じ分野のオンラインマニュアルを探してそれに見合った単語をつけるのがいいというのは、知らなかったので自分の対象分野のオンラインマニュアルを探してみたいと思います。
オブジェクトに名前をつけることで、そのオブジェクトがどういう振る舞いをするのかが見えてきます。
「契約による設計」という言葉が出てきたのですが、これは以前参加した「LOG.debug("nice catch!") に参加してきました #java_ja」の@t_wadaさんの資料にも出て来ました。
オブジェクト指向設計を適用させることでif文のネストを減らすことが出来るようになります。そうすることで、仕様変更にも対応する場合でもネストを深くするのではなく、オブジェクトだけに注力出来るので、既存のテストへの影響範囲も視覚的にわかるのではないかと思います。
クラスをラップしておくことの利点は、オブジェクトをimmutableであることを明示できることだと思います。
コレクションクラスは、java.util.Collectionsでunmodifiableにすることもできますが、例外を使うよりラップしてput、add出来ないようにするほうが分かりやすいと思います。
その他にもMapのようなクラスを使う場合では、予めオブジェクトにNullObjectパターンを適用させておくことで、nullチェックを減らすことが出来ます。
例えば、java.util.Mapをそのまま使ってしまうと、自由に値を操作されてしまう可能性を残しているので、それに対する防御的プログラミングをしなければなりません。また、キーを元に値を取得する際に、NullチェックをそのMapを利用している箇所全てで行わなければなりません。
それは、変更があった場合全ての箇所で適用させなければならないので、必ず漏れ、ミスタイプ等が発生します。
こういったミスを予め減らすことが出来るのであれば、ぜひやるべきでは無いかなと感じました。
カプセル化でよく言われるgetter/setterについても、フレームワークなら使ってもいいけど、人間が使うのを避けるために@Deprecatedにするといった、使わないところをきちんと明確にすることで減らすことが出来るというのを知りました。
最後に、行数を制限することでコードの不吉な匂いを嗅ぎ分ける訓練が出来るようになると感じました。
ネストが深くなったり、setterをひたすら書いていたりなど、行数を稼ぐ何かしらのコードが出てくることは、何か間違っている傾向が見られるということです。
これらをいきなり現在のプロジェクトに適応させていくのは、かなり困難な道を歩んでいくと思われます。
ですが、まずこのエクササイズを行えるようなプロジェクトでまず試して、チーム全員が慣れてから挑むのがいいのではないかなと思います。
- インデントは１つまで
- else句は使わない
- プリミティブとStringはラップする
- 一行にドットはひとつ
- 名前は省略しない
- クラスは50行、パッケージは10個以内
- インスタンス変数は２つまで
- ファーストクラスコレクション
- getter/setterを使わない
オブジェクトを小さくバラバラにする理由は、隣同士の繋がりだけに落としこむことで全体を知らなくてもうまく動かせるようにするためということです。
こうすることでテストを行う際もモックで置き換えることが出来るので対象範囲を狭くすることが出来るのではないかなと感じました。
小さくするということで重要になってくるのは、オブジェクトにどのように名前をつければ、バラバラになっても分かりやすくなるのかということだと思います。
そのためには、省略せず対象分野の言葉を使うのが一番です。
英語で名前をつけるのが殆どなのですが、辞書を引いたままの言葉よりも同じ分野のオンラインマニュアルを探してそれに見合った単語をつけるのがいいというのは、知らなかったので自分の対象分野のオンラインマニュアルを探してみたいと思います。
オブジェクトに名前をつけることで、そのオブジェクトがどういう振る舞いをするのかが見えてきます。
「契約による設計」という言葉が出てきたのですが、これは以前参加した「LOG.debug("nice catch!") に参加してきました #java_ja」の@t_wadaさんの資料にも出て来ました。
例外設計における大罪 from Takuto Wada
オブジェクト指向設計を適用させることでif文のネストを減らすことが出来るようになります。そうすることで、仕様変更にも対応する場合でもネストを深くするのではなく、オブジェクトだけに注力出来るので、既存のテストへの影響範囲も視覚的にわかるのではないかと思います。
クラスをラップしておくことの利点は、オブジェクトをimmutableであることを明示できることだと思います。
コレクションクラスは、java.util.Collectionsでunmodifiableにすることもできますが、例外を使うよりラップしてput、add出来ないようにするほうが分かりやすいと思います。
その他にもMapのようなクラスを使う場合では、予めオブジェクトにNullObjectパターンを適用させておくことで、nullチェックを減らすことが出来ます。
例えば、java.util.Mapをそのまま使ってしまうと、自由に値を操作されてしまう可能性を残しているので、それに対する防御的プログラミングをしなければなりません。また、キーを元に値を取得する際に、NullチェックをそのMapを利用している箇所全てで行わなければなりません。
それは、変更があった場合全ての箇所で適用させなければならないので、必ず漏れ、ミスタイプ等が発生します。
こういったミスを予め減らすことが出来るのであれば、ぜひやるべきでは無いかなと感じました。
カプセル化でよく言われるgetter/setterについても、フレームワークなら使ってもいいけど、人間が使うのを避けるために@Deprecatedにするといった、使わないところをきちんと明確にすることで減らすことが出来るというのを知りました。
最後に、行数を制限することでコードの不吉な匂いを嗅ぎ分ける訓練が出来るようになると感じました。
ネストが深くなったり、setterをひたすら書いていたりなど、行数を稼ぐ何かしらのコードが出てくることは、何か間違っている傾向が見られるということです。
これらをいきなり現在のプロジェクトに適応させていくのは、かなり困難な道を歩んでいくと思われます。
ですが、まずこのエクササイズを行えるようなプロジェクトでまず試して、チーム全員が慣れてから挑むのがいいのではないかなと思います。
おわりに
電脳書房さんで、ThoughtWorksアンソロジーが出品されていたので、早速購入してみました。
今のところおすすめされた本を一つづつ消化しています。
全てを読んで振り返った時にまた新しい気づきが生まれるのではないかと思うと、楽しみです。
今後のことを考えた時にふと感じたのは、以下のようなことです。
Java8を現場レベルで使えるのはいつになるか分かりませんが、オブジェクト設計エクササイズも変わっていくのかなと思いました。
増田さん、主催のLearning Community Factoryの方々、会場を提供してくださった楽天様ありがとうございました。
次回が開催されることを楽しみにしております。
電脳書房さんでポチッたThoughtWorksアンソロジー届いた。初版とは思えないくらいきれい。 instagr.am/p/W8NvGVP8p8/
— とーますさん (@grimrose) 2013年3月17日
今のところおすすめされた本を一つづつ消化しています。
全てを読んで振り返った時にまた新しい気づきが生まれるのではないかと思うと、楽しみです。
今後のことを考えた時にふと感じたのは、以下のようなことです。
Java8から導入されるlambdaだとメソッドチェーンでcollection操作出来るんだけど、ドット一つの制限だとキツイような気がする。 #lcfactory
— とーますさん (@grimrose) 2013年2月23日
Java8を現場レベルで使えるのはいつになるか分かりませんが、オブジェクト設計エクササイズも変わっていくのかなと思いました。
増田さん、主催のLearning Community Factoryの方々、会場を提供してくださった楽天様ありがとうございました。
次回が開催されることを楽しみにしております。
