「エンジニアが成長できる環境を提供する」株式会社リヴェラの様子をご紹介します!

「エンジニアが成長できる環境を提供する」株式会社リヴェラの様子をご紹介します!

社会人3年目がオブジェクト指向について語ってみる(その1)

2018.12.28

社会人3年目がオブジェクト指向について語ってみる(その1) はコメントを受け付けていません。

はじめに

こんにちは、さばです。

月日が流れるのは早いもので、今年ももう終わりですね。

今年の現場はJava尽くしの1年でした…楽しいから良いんですけど!

年末ということで何かまとめ的な記事を書きたいなと思いましたので、社会人3年目である私が今までの業務をベースに「結局オブジェクト指向とはなんぞや」ということについて書こうと思います。

誤った解釈等もあると思いますので、あくまで参考レベルで見て頂けたら幸いです。

長くなったので分割しています。

この記事ではオブジェクト指向の目的と手段に焦点を当てて語っていきます。

この記事で触れること

  • オブジェクト指向の解釈についての感想
  • オブジェクト指向の目的
  • 読みやすいソースコードとは

最初に根付いたオブジェクト指向の解釈

私が社会人1年目で受けたJava研修内で説明された「オブジェクト指向」は大雑把に以下の通りだったと思います。

(私の解釈です。他の人は違っていたかもしれません…)

  • オブジェクト指向とは、「継承」「多態性」「カプセル化」を主軸にプログラミングを行う手法
  • 利点として、プログラムの拡張や修正が簡単になる
  • 継承とは、似ているオブジェクトの部品を共通化して抽象的にすること
  • 多態性とは、同じ抽象概念として扱われるオブジェクトが、それぞれ違う振る舞いをすること
  • カプセル化とは、外部から見た時に無駄な情報を隠匿すること

他に覚えているのは、継承の説明として、犬クラスと猫クラスは動物クラスを継承するように設計して、犬 is a 動物みたいに「is-a関係」を保つようにすると習いました。

多態性やカプセル化についてはどんな説明を受けたかいまいち覚えていません…

当時の私は「なるほど~」となって、オブジェクト指向についてわかったつもりになっていました。

上記で記した解釈は最初のものを除いて大体合っていると思います。

最初の項目に関して言うと、これらはあくまで「手段」であり、オブジェクト指向が目指すところの「目的」ではないと思っています。

つまり、オブジェクト指向には何か「目的」があって、「継承」「多態性」「カプセル化」という「手段」を使えば忠実に目的を実現できるということですね。

私はそこの「目的」をいまいち理解しないまま、オブジェクト指向をわかったつもりになっていました。

今回は、業務を通じてプログラミングをするにつれてなんとなくわかってきた「目的」と、なんでそれらの「手段」を使うべきかという点について考えていきます。

オブジェクト指向でプログラミングする目的とは

結局のところ、最終的な目的は以下だと思っています。

業務知識のない人間でも、コードを読めば業務を理解することが出来るようにするため

つまりコードを読めば誰でもアプリケーションで扱っている業務内容を理解することが出来ることを目指しているということです。

そういったコードを目指した結果、「プログラムの拡張や修正が簡単になる」という「利点」が得られるのだと思います。

何故なら、「業務内容を理解する⇒修正するべき業務や拡張が必要な業務を考える」ということを、コードを通じながら直接考えることが出来て、そのまま反映することが出来るからです。

これを実現するためには、以下の様なことが必要不可欠です。

  • ソースコードは誰が読んでも業務内容がわかるようにする

そしてこれを実現するための具体的な手段として、以下の様なものが挙げられると思います。

  • ソースコードのまとまりをなるべく小さくして読みやすくする
  • ソースコードの内容を出来るだけ簡単にする
  • なるべく文として読めるようなソースコードを目指す
  • 専門的な業務知識で分かり辛い所にはコメントを付ける

ソースコードのまとまりを小さくしたり簡単にすれば、頭が混乱せずに理解を深めることが出来ます。

文として読めるようなソースコードが書ければ、業務やプログラミングを理解していない人でもソースコードから業務内容を理解できます。

そしてわかり辛い業務知識にコメントがついていれば、辞書やインターネットで調べる必要が無くなります。

他にもいろいろな手段があると思います。

ここまでオブジェクト指向についての「目的」と「手段」について語りました。

次はこれら「手段」をプログラミングに落とし込んでいきます。

読みやすいソースコードとは

ではどうやれば「まとまりが小さく」「簡単で」「文として読める」ソースコードを書けるのでしょうか。

私が業務内で学んだやり方は以下の通りです。

  • まとまり一つの関心毎は一つまでにする
  • まとまりの中で定義する業務ロジックの分岐を制限する
  • 業務ロジックに名前を付ける時は、英語でパッと見て何をやっているかわかるようにする

まとまり一つの関心毎は一つまで

以下、まとまりのことを集合体と言うことにします。

関心毎とは、その集合体が知っている情報のことです。

例えば、ゲームコントローラーという名の集合体があったとします。

この集合体は「ゲームコントローラー」のことしか知ってはならないというのが一つ目の言っていることです。

「ゲームコントローラー」は「ゲームコントローラーについているボタン」についての情報は知っていても良いですが、「ゲームソフト」についての情報は知っていてはいけません。

要するに「ゲームコントローラー」の中で「ゲームソフト」に関係する業務ロジック(例えばあるボタンを押すとソフト内のキャラが歩く等)は定義してはいけないということです。

「ゲームコントローラー」が知っていて良いのは「ボタンを押したか」までで、「ボタンを押すとどうなるか」は別の集合体で定義されるべきです。

まとまりの中での業務ロジックの分岐を制限

二つ目の言っていることは、業務ロジック内での条件分岐を出来るだけ少なくするということです。

分岐は1ネストが良いです。2ネスト以上になると読みづらくなる印象です。

ネストとは分岐の深さのことです。

例えば以下の様な業務ロジックは1ネストです。

ボタンを押していたら1を送る、それ以外は0を送る

以下の様な業務ロジックは2ネストになります。この場合は1ネストになるように業務ロジックを分割した方が良いです。

Aボタンを押している状態でBボタンを押していたら1を送る、それ以外は0を送る

具体的には以下の様に分割します。

[ABボタン同時押下判定処理]
Aボタンを押していたら[Bボタン押下判定処理]を呼び出し、その結果を送る。それ以外は0を送る。

[Bボタン押下判定処理]
Bボタンを押していたら1を送る。それ以外は0を送る。

かなり簡単な例で説明しましたが、これがもっと複雑になってくると頭が混乱してきます。

名前は英語でパッとみてわかるように

業務ロジックの名前はパッと見て分かるのが適切です。

例えば、ゲームコントローラー内にgetButtonFlgという業務ロジックがあったとします。

パッと見で「ButtonFlgを取得する」ということをしているのはわかりますが以下の様な疑問が生じます。

  • ButtonFlgって何者?フラグ値?
  • 仮にフラグ値だったとして、フラグ値がTrueだったら何があるの?

これを回避するために、isPushedButtonのような名前に修正します。

これなら「この業務ロジックはボタンが押されていたらTrueを返すんだな」ってことが見てわかります。

おわりに

ここまで、オブジェクト指向の「目的」と、それを実現するための具体的な「手段」について語ってきました。

本記事ではあえて「クラス」「オブジェクト」等のプログラミング的な用語を使うのを避けています。

次の記事ではもっとプログラミング用語に落とし込んで説明していく予定です。

来年になったらすみません…

関連記事

コメントは利用できません。

エンジニア募集中!

株式会社リヴェラ Webページ