ちゃんとオブジェクト指向できていますか？

こんにちは、星影（@unsoluble_sugar）です。

6月11日、DevLove主催のイベント「オブジェクト指向でコードが書けるようになろう。」に参加してきました。

今回はCodeIQさんの協力のもと、オブジェクト指向設計をテーマとして開催されました。

会場

会場は、銀座にある「リクルート メディアテクノロジーラボ」さんの「リクルート アネックス１ビル」地下１階でした。

写真を撮り忘れてしまいましたが、オシャレすぎてチビリそうになりました。勘弁して下さい。

参加動機

僕はこれまで、JavaやC++、PHPと、いくつかのオブジェクト指向言語を扱ってきたのですが、「ちゃんとオブジェクト指向できていますか？」という問いかけに対して、迷わず「はい」と答えられる自信がありませんでした。

前職での各プロジェクトでは、先輩方のご助力を得ながら何とかそれっぽい感じにコードを書いてきたつもりです。しかしながら、次のキャリアへ進む前に、オブジェクト指向設計というものをしっかりと身につけておきたいという気持ちがありました。

また、他社のエンジニアの皆さんがどのようなやり方で、オブジェクト指向設計を行なっているかにも興味があり、今回の参加を決意しました。

クラス名を考えてみよう

CodeIQに問題を提示していただいた、有限会社システム設計の増田 亨さんを話し手としてお迎えし、レクチャー&ディスカッション形式で進められました。
今回は、増田さんがCodeIQに出題した『クラス名を考えてみよう』を題材として、参加者同士がそれぞれの考えについてグループディスカッションしました。

※現在、CodeIQ上の問題は既にクローズしています。

星影の回答

僕の回答としては、クラス名は全部で２つかな、と考えました。

• 入力情報を保持するクラス：UserInfo
• チェックを担当するクラス：CheckUserInfo

情報を持つクラスと、チェックを担当するクラスを分離した設計です。もしくはクラスは１つだけにしてしまって、クラス内にメソッド増やせば良いかなぁ、と。

僕は事前にCodeIQの問題は解いていたのですが、増田さんから以下のようなフィードバックを受けていました。

別のスタイルとして、

◎情報と、その情報を使うロジックは同じクラスにまとめる。
◎クラスの変更理由は一つになるようにクラスを分ける。（単一責任の原則）

があります。

たとえば、

・パスワードの情報とそのチェックロジックをひとかたまりにして、Password クラスにする。
・同じように、名前は Name, メールアドレスは、MailAddress 、など。

こうするとパスワードの入力チェックルールが変わった時、影響するクラスは、Password クラスに限定できます。

確かに単一責任の原則に従えばクラス数はもっと多くなりますね。このフィードバックを読んで、少し安易に考え過ぎたなぁ…と反省。当日は、他の方の意見も聞きたかったので、とりあえずこの設計案をもとに意見を述べました。

グループディスカッション

グループディスカッションでは、各自が考えた案を発表し、意見交換を行いました。僕のグループでは、3パターンの回答が出ました。

• クラス数２つ：情報を持つクラスと、チェックを担当するクラス
• クラス数５つ：Member / Email / Name / Password / AccountChecker
• クラス数９つ：MenmberCreateRequest / LengthChecker / AlnumChecker / SameChecker  / EmailChecker / TypeIncludeChecker / TypeIncludeCheckerクラス配下にチェック用クラス x 3

「クラス数９つ」という意見には少し驚きましたが、僕が主にメソッド単位でやろうとしていたことをクラス定義として設計されていたようでした。その考えを聞いて納得しました。やっぱり僕、オブジェクト指向できてないなぁ…と(； ･`д･´)

グループ発表

グループディスカッションのあと、グループ単位での発表が行われました。

全体の比率だけで見れば、クラス数２つという意見が多かったのですが、クラスを細分化された方の意見は、どれを聞いても「なるほど、そういう発想もあるなぁ…」と、終始考えさせられました。

増田さんからのフィードバックにもあったとおり、各チェックロジックをひとかたまりにするという案も、かなり多かったです。定義するクラス数の違いは、オブジェクト指向の「単一責任の原則」に基づいているか否かで、案が分かれたものと感じました。

また、クラスの名前付けが人によってだいぶ異なるんだなぁ、という印象を受けました。チェックひとつにしても、「Check xxx」「xxx Checker」「xxx Validater」などのバリエーションが出ました。

人によって名前付けのルールに違いが見られることは理解していたつもりですが、会場でははじめて耳にする単語も多く、大変勉強になりました。名前付けについては、開発者間で共有しておく必要はありますが、単純にボキャブラリーを増やすことによって、様々なケースに直面した場合にも柔軟な対応ができそうですね。

増田さんの解説

各グループの意見発表後、増田さんから問題の解説をいただきました。すべては書ききれないので、僕が気になったものだけ抜粋させていただきます。

仕様の一歩先へ

• 仕様だけ満たすだけではなく、もう一歩先へ進んでほしい

この一言は重かったです。頭では分かっていたつもりですが、今回の問題についても、自分はまだまだこれからという感じです。色々な角度からの提案ができるようになりたいですね。

和製英語について

• 和製英語結構！日本人同士で伝わりやすければ問題ないんじゃない？

僕はあまり使った経験はありませんが、確かに開発者間で共有できていれば何も問題ありませんね。

Validaterについて

• お客様目線で言えば、ValidaterよりもCheckerの方が伝わりやすいのでは

これについては、僕も普段から開発者目線の専門用語を多用してしまう時があるので、なるべく避けるようにつとめています。

データクラスに “Signup” や “MenmberCreateRequest” を定義

• 文脈からして良い名前

僕は思いつかなかった単語です。こういうのがサラッと出る人に憧れてしまいます。ボキャブラリーは少しずつ増やしていきたいですね。

名前が見つからない…

クラス名が見つからない→メソッドが増える→コード肥大化→楽しいリファクタリングの時間！＼(^o^)／ #devlove

— 星影 (@unsoluble_sugar) 2013年6月11日

どうみても僕です本当にどうもありがとうございました。

リファクタリングには皆さん苦労されているようですね…

増田さんの設計のスタイル

• 単一責任
• データ＋ロジック
• 関心事の分離
  • プレゼンテーションとモデルの分離
  • 技術的関心とモデルの分離

• 手続き的な設計とオブジェクト指向らしい設計

増田さんが良いと思う設計

• 変更した時にわかりやすく、いじった時に他の部分の影響を心配する必要のないもの
• データの発生、変更のタイミングが同じものはまとめておく。変更のタイミングが異なるなら別にする
• ペアプログラミングだけでなく、ペアモデリングもやるべき

まとめ

今回、DevLoveのイベントには初めて参加させていただきました。

プログラミングスキルをもっと学びたいという方、オブジェクト指向を部下に教えたいという方、フリーランスでオブジェクト指向を追求しているという方など、様々な境遇の方とお話ができて純粋に嬉しかったです。オブジェクト指向について、ほんの少しですが楽しく学ぶことができました。

色々なお話が聞けましたが、やっぱり設計って大事だなと改めて考えさせられました。あと人の話を聞くこと大事。超大事。お客さんと話すことはもちろん、社内の開発者間だけでなく、外部の人の話を聞くことで発想力が養われていくんだなぁ、と思いました。

そしてもっと大事なのは自分の意見をしっかりと主張できること。相手を言い負かそうというわけではなく「自分の考えはこうである」という思いをきちんと述べられる人は、それなりのスキルやバックボーンを抱えているということが感じられます。

残念ながら今の僕には、それが圧倒的に足りません。少しでも皆さんに追いつきたい。そしていつか追い越したい。そんな思いを胸に抱き、これからも精進していきたいと思います。

謝辞

最後になりましたが、主催のDevLove運営の皆さん、CodeIQの皆さん、増田さん、会場提供してくださったリクルート メディアテクノロジーラボさん、そして参加者の皆さん、本当にありがとうございました！