実践！オブジェクト指向　文系出身ひよっこエンジニアの勉強記

こんにちは、弥生の野川です。

この記事はMisoca+弥生+ALTOA Advent Calendar 2018の23日目のエントリーになります。いよいよクリスマスが目前ですね！

簡単に自己紹介をさせていただきます。

・2018年4月に弥生に新卒入社
・入社以前にプログラミングの経験は全くなし（学生時代は文系の学科に所属）
・入社後のJavaの研修でプログラミングに興味を持ち、開発の部署への配属を希望
・現在は自動テストを開発・運用するチームでエンジニアとして奮闘中（歴6ヶ月）

今回はこんな私が、オブジェクト指向について勉強して思ったことを書き連ねます。

はじめに：一般的なオブジェクト指向の説明

一般的な参考書では、オブジェクト指向は以下のように説明されることが多いかと思います。

対象（オブジェクト）そのものに重点をおき、対象のふるまいや操作が対象の属性として備わるという考え方。
現実世界の部品（モノ）をモデリングし、プログラムに置き換えるという考え方。
オブジェクト間のメッセージ・パッシングでプログラムを動作させるという考え方。

しかしながら、プログラミング未経験者にこの説明は本当にキツイ！なぜかと言いますと・・・

初心者はここがわからない

「オブジェクト指向」という名前に馴染みが1ミリもない。
「対象に重点をおく」のは良いけど、おいてどうするのかがわからない。
「ふるまいや操作が属性として備わる」のイメージがつかめない。
「現実世界のモノをプログラムに置き換える」なんてできるんですか？って思う。
「オブジェクト間のメッセージ・パッシング」がまるで呪文のように聞こえる（つまり何もわからない）。

などなど、初心者の前には高すぎる壁が立ちはだかります！（よくこれでへこたれずに勉強したな自分・・・）と思うぐらいです。

オブジェクト指向はこうして理解する

そんな壁を乗り越え、私がオブジェクト指向を理解することができたのは、以下のことを実践したおかげでした。

とにかく複数クラスのプログラムを実装してみる
先輩エンジニアと話す
複数人での開発を、身をもって経験する

これだけです。しかしこれが私にとってはすごく重要でした。

1. とにかく複数クラスのプログラムを実装してみる

　概念を文字だけで理解しようとするのではなく、実際にメインクラスで他クラスをインスタンス化してメソッドを呼び出すプログラムをいくつか書くと、「オブジェクト間のメッセージ・パッシング」は呪文ではなくなりました。

特に引数・戻り値を使うメソッドだと良いです。メッセージ・パッシングめっちゃ楽しい～！ってなります。

　また、オブジェクト指向に特有な「継承」「ポリモーフィズム」などの考え方も、実装してみないことには、なぜ必要か、どのような時に必要になるのかがわからないんですよね。

　私もそうなんですけど、文系出身の人間には結構ありがちな「概念を理解しないと先に進めない！」という思考は、オブジェクト指向の勉強ではちょっと横に置いておくのが良さそうです。

2. 先輩エンジニアと話す

　自主勉強の一環で、トランプのゲームを実装している時のことです。 1枚のカードを表すカードクラスはサッと実装できたのですが、束になったトランプクラスを作ろうと思ったところで手が止まりました。

「た、束・・・!?」

私が悩んでいると、プログラミング経験のある同期と大ベテランの先輩が声をかけてくださって、トランプクラスについて一緒に議論してくれました。ポイントは、「そこにあるかのように、トランプの束の状態を想像すること」でした。

・トランプの束に含まれているカードは、4種類のマーク×13の数字の組み合わせで、計52枚。
・カードの引き方は、束の好きなところから引くパターンや、
　山の上から１枚引くパターンがある（ゲームによる）。
・カードが引かれると、そのカードは束の中からなくなる。

などなど、トランプの特徴を1つ1つあげて、それらに対応するように実装していくとまさに現実世界のトランプ（＝モノ）をプログラムで実現することができました！下図は、束の好きなところから引くパターンで実装しました。 f:id:kenta_nakayama:20190116100338p:plain

このレベルの話を先輩エンジニアとする必要が果たしてあるのか？と思われてしまいそうですが、私は一人で中身を考えていると、合っているのか間違っているのかもわからずモヤモヤしてしまいます・・・。先輩エンジニアが「うんうん、そうそう」と言ってくださるだけで脳内の設計が明快になるので、とてもありがたいです。

3. 複数人での開発を、身をもって経験する

　ソフトウェア開発では、機能ごとに分担して実装したり、既存のコードを別の人が後になって改修したりということが当たり前のように行われています。

しかし、私はエンジニアになるまで、ソフトウェア開発の工程なんて全く気にしたことがなかったので、オブジェクト指向の目的である「効率化」「保守性」の必要性もわからないというレベルでした。

最近ようやく、私も開発プロセスの一端を担うようになったので、「開発ってみんなで分担してやるから、機能ごとに分かれてると開発・改修しやすいんだな～」ということを肌で感じることができています。

このイメージを持てた瞬間、オブジェクト指向への親しみやすさはぐんと跳ね上がりました。特に、なぜこんなにもアクセス修飾子を気にしないといけないのか、その理由がよくわかるようになりました。仕事では、既存の自動テストが安定して動作するようにコードを改修することが多いのですが、いじるものがprivateメソッドだと、あまりびくびくせずに変更を加えることができます（笑）