オブジェクト指向プログラミングで作るとき、どういうソースコードにするか

はじめに

いろんな人が書いていますが、オブジェクト指向プログラミングでプログラムを作るときの説明を、自分も短めに書いてみました。

オブジェクト指向をざっくり知っていて、オブジェクト指向プログラミングでどうすればいいか分からない人向けの説明です。
具体例は書いてないけど短め。

自分なりの理解で書いたの内容なので、参考くらいに見てください。

オブジェクト指向プログラミング

とりあえず、Wikipediaの
「オブジェクト指向プログラミング」『フリー百科事典　ウィキペディア日本語版』2021年3月16日 (火) 08:32
から引用。

オブジェクト指向プログラミング（オブジェクトしこうプログラミング、英: object-oriented programming、略語:OOP）とは、互いに密接な関連性を持つデータ（変数またはプロパティ）とコード（関数またはメソッド）をひとつにまとめてオブジェクトとし、それぞれ異なる性質と役割を持たせたオブジェクトの様々な定義と、それらオブジェクトを相互に作用させる様々なプロセスの設定を通して、プログラム全体を構築するソフトウェア開発手法である。

上手くまとまっていて、これ以上は言うことはないです。

プログラムの完成形の説明としてはこれで十分なのですが、どうプログラムをつくるかわからないと思います。

オブジェクト指向プログラミングのメリット

まずは、何のためにオブジェクト指向を使うかということから。

オブジェクト指向プログラミングは分かりやすい、理解しやすい、読みやすいプログラムを作るためのものです。
もう少し具体的に言うと次のようなプログラムにするため、オブジェクト指向を使います。

• ソースコードをクラス(オブジェクト)という名前のある固まりにして分かりやすくする。
  • 視覚的にイメージしやすい。
  • クラスの形だと使いやすい。
  • どのクラスにソースコードが実装されているか推測できる。
• どういうソースコードになっているか知らなくても、クラス(オブジェクト)が使える。
  • プログラムを作るとき、読むときにクラスのソースコードを気にせず必要なところだけ考えればいい。
  • 覚えておくことを少なくできる。
• 拡張しやすいプログラムが作れる。
  • クラスを組み替えることで動作を変えることができる。

オブジェクト指向プログラミングで作るとき、どういうソースコードにするか

オブジェクト指向のメリットは挙げましたが、オブジェクト指向プログラミング言語で作れば、メリットが得られるわけではありません。

逆に言うと、メリットを得られるようにプログラムを作る必要があります。

クラス(オブジェクト)という名前のある固まりにする

プログラムで必要な処理やデータに名前を付け、名前を付けたクラスに関連するソースコードはできるだけそのクラスに作成するようにします。

名前と関係の薄いソースコードは、別のクラスにするようにします。

クラスのソースコードを知らなくてもクラスが使えるようにする

クラスは外側からみてどうなっているかを意識しながら作る必要があります。
こんな感じのものが、良いクラスだと思います。

• 何をするクラス/関数かわかりやすい。
• 説明がなくても使えるクラス/関数になっている(できるだけ)。
• 公開されている関数、変数が少ない。
• 関連するクラスが少ない(クラス使うのに必要なクラスとかあったら困る)。

作る側から表現するとこうなります。

• 何をするクラス/関数かわかる名前をつける。
• 使うときの前提条件とか準備とかはなくす(減らす)。
• 外から使うときに必要な関数だけ公開する。
• クラスの関数、変数に使うクラスを少なくする。

拡張しやすいプログラムにする

上に書いたように作ると、ある程度拡張しやすいソースコードになります。

また、インターフェースやデザインパターンを使うと、拡張しやすいプログラムを作ることができます。

オブジェクト指向プログラミングは難しい

これで終わりですが、実際のプログラミングは難しいと思います。

オブジェクト指向プログラミングにはオブジェクト指向プログラミング言語と関数化の能力に加えて、クラスを作る能力も必要となります。
手続きとかアルゴリズムとかと違った思考です。
これは、プログラミング言語を勉強しても、たいていの場合は一緒に書いてあるものではないはずです。

学習も少し難しいと思ってます。
ざっくりした方法論だったり、よくある形だったり、従ったほうがいい原則だったりがありますが、あまりまとまっていなかったりします。

また、どんなクラスを作るかにはトレードオフがあり、正解がありません。
「このクラスを作る/作らないと、この部分が簡単になる」だったり、「このクラスを作ると、この部分に機能追加しやすくなる」だったりということがあるため、必要なクラスを必要な分だけ作成するという形にする必要があります。

順に作っていっても、たぶん途中でクラスを増やしたり減らしたり、関数を移動させたりしないといけなかったりします。

おわりに

具体的な話とか用語とか書いてないですが、方向性としてはこんなだと思っています。