そもそもオブジェクト指向とは？
データと処理をまとめて書くスタイルのプログラム
各プログラムをオブジェクトという“モノ”として組み立てて、そのオブジェクトを組み合わせてシステム全体を構築するのがオブジェクト指向です。
従来の開発手法では、データと処理をバラバラに記述していました。オブジェクト指向は、関連するデータと処理を1つのグループにまとめるのが特徴。実務のコーディングでは、オブジェクト指向で書かれていることがほとんどです。
オブジェクト指向は1960年代に登場。コンピューターがどんどん発達して複雑な処理も可能になる中、ノルウェーのオーレ＝ヨハン・ダールとクリステン・ニガードによって提唱されました。
その後1970年代にXerox PARCでアラン・ケイらがオブジェクト指向をベースにしたプログラミング言語「Smalltalk」を開発。1980年代以降になると今でも使われているC++やObjective-Cが生まれ、オブジェクト指向のプログラミング言語が広く使われるようになりました。
オブジェクト指向がわかりにくい理由
オブジェクト指向がなかなか理解できない大きな理由は2つ。1つはオブジェクト指向自体が抽象度が高いから、もう1つは教える側との知識の差があるからです。
カプセル化・ポリモーフィズムなど、参考書に出てくる用語は難解かつ実際のソースコードとの関係性がイメージしづらいものばかり。未経験エンジニアは用語だけでなく概念の理解に苦しむケースが多いです。内容を理解しようと、何度読んでも実務に落とし込みにくい抽象度の高さが難易度を上げています。
また、教える側と学ぶ側の認識のズレも、挫折を生む要因です。開発の全体像が見えていないにも関わらず、ベテランエンジニアは当たり前のように専門用語を使います。新人は言葉の意味を調べるだけで時間が過ぎ、「何もできなかった」と本人が焦ってしまって実務に集中できなくなります。
わかりにくさと焦りが、新人エンジニアを追い込んでいるともいえるでしょう。
なぜオブジェクト指向のプログラムがたくさん使われているの？
一度仕組化すれば何度でも使い回せるから
オブジェクト指向最大のメリットが効率的な再利用性です。一度作成したプログラムの部品は、別の場所で何度でも再利用可能なので、特に大規模なシステム開発において開発期間の短縮につながります。バグが発生した際も、該当の部品を修正するだけで対応可能です。メンテナンスの手間が減るため、開発現場の負担を軽減します。
オブジェクト指向で書かれたコードは、仮に一部を変更しても全体に悪影響を及ぼしにくいので機能改修も簡単にできます。また一定のルールを守る前提なので、どのエンジニアでも同じコードを書くことができ、エンジニア間の意思疎通も容易になります。
誰でも同じものを出力でき、安全に拡張できるからこそ、多くの開発現場で採用されているのです。
超初心者でもわかる！オブジェクト指向のイメージ
.png)
設計図（クラス）と実体（インスタンス）
オブジェクト指向を考えるうえで非常に重要な概念が、クラス（Class：設計図）とインスタンス（Instance：実体）です。
クラスはオブジェクトを作るための設計図のようなものです。クラスを準備する際は、以下の要素を盛り込んで準備します。
こうした要素を盛り込み、できあがるのが実体であり、オブジェクトであるインスタンスです。車の設計図がクラス、その設計図をもとに量産された車がインスタンスといえます。
ただ、まだイメージが湧きにくいかもしれません。そこで次章でもっとわかりやすいものに例えて解説しましょう。
オブジェクト指向をRPGに例えてみよう
ということで、この記事ではオブジェクト指向をロールプレイングゲーム（RPG）のパーティーに例えましょう。
RPGの登場人物には、何かしらの職業が割り当てられています。主人公はたいてい勇者で、魔法使いや踊り子、僧侶、パラディンなどいろいろな職業の登場キャラクターが存在します。この職業はいわばクラス。RPGの職業に例えるならこのようなイメージです。
こうしたステータスはゲームを作った側が設定して、各キャラクターに当てはめられます。ただ、同じ職業でもステータスが全く一緒にはなりません。例えばこのようなイメージです。
同じクラスを用いて別のキャラクター、つまりインスタンスができあがります。インスタンスはプロパティによって差が出ることがあり、今回のようにタロウとジロウのステータスに差が出るのはよくあることです。
そして、インスタンス同士は干渉しないので、タロウがダメージを負ってもジロウの身には何も起きません。ジロウがレベルアップしてMPが増えても、タロウのステータスには影響が出ません。
続いてタロウとジロウ、そして魔法使いのハナコのパーティーがいるとしましょう。彼らは旅をする途中でモンスターに出会い、戦闘に入りました。この時に「たたかう」と指示を出して攻撃をすることになりますが、職業やキャラクターによって出す攻撃が変わることもよくありますよね。このようなイメージです。
タロウ…敵に近づいて大きな剣で切りかかる
ジロウ…小さな剣を投げる
ハナコ…その場にいるモンスター全員にダメージを与える魔法をかける
このように、オブジェクトそれぞれに同じ指示を出しても動作が変わります。同じ指示でも動作が変わるのも、オブジェクト指向ならではの特徴です。
この後、オブジェクト指向を理解するためのワードについて説明しますが、その中でもこのRPGのパーティーで例えながら説明していきましょう。
オブジェクト指向を理解するために重要な3つのワード
①カプセル化
データを外部から保護する仕組みがカプセル化です。内部の複雑な処理や重要なデータを隠して外部から勝手にデータを書き換えられるリスクを減らし、安全性を高める仕組みです。
これを施していないと、インスタンスの中身が簡単に書き換えられてしまいます。RPGにおけるパーティーの筆頭であるタロウのHPを勝手にゼロにして即死させる、もしくはかつてのバグ技のようにHPをシステム上扱える最大値にして無双するような操作もできてしまいます。これではゲームが面白くないですよね。
なので、どうしてもステータスを変えたいときは専用の処理を通すルールを設定。このとき不正な数値をチェックする機能を処理の内部に組み込めば、バグが発生しないよう制御もできます。
実務面では、開発者が他人が作った部品の内部を気にせず使えるため、開発効率が上がります。カプセル化はチーム開発を円滑にする知恵ともいえるでしょう。
②継承
既存の設計図を元に、新しい設計図を作る仕組みが継承です。過去の資産を引き継ぐため、開発のスピードが上がります。子クラス側での処理設定次第ではあるものの、原則親クラスに共通処理をまとめておけば修正箇所を集約しやすくなります。
先ほどのRPGのパーティーに、新しくパラディンのルイが加わったとしましょう。パラディンのステータスは勇者にかなり近く、違うところと言えば弓が使えて馬に乗れること。このパラディンのステータスを作る場合、「勇者の能力はそのままで、弓が使えることと馬に乗れることを追加する」と指示すればよいのです。
こうすることで重複するコードを書く無駄がなくなり、プログラムがすっきりします。その後のメンテナンスもしやすくなり、保守運用上のデメリットが大きく減ります。継承を上手に使いこなせば、開発の生産性は飛躍的に向上するでしょう。
③ポリモーフィズム
同じ命令に対して、異なるオブジェクトがそれぞれの動きをする仕組みがポリモーフィズムです。先ほど紹介したRPGにおいて、同じ指示を出してもやることが違うと話しましたが、これこそポリモーフィズムの最たる例です。パーティーが4人になった今、「たたかう」のコマンドを入れるとこんな動作をします。
タロウ…敵に近づいて大きな剣で切りかかる
ジロウ…小さな剣を投げる
ハナコ…その場にいるモンスター全員にダメージを与える魔法をかける
ルイ…一番HPが残っているモンスターに向けて弓を放つ
仮に新しいインスタンスが加わっても、命令を出す側のコードを変更なしで攻撃できます。周囲への影響を最小限に抑えながら、新しい機能を追加できる設計です。柔軟性の高いシステムを作るために、プロのエンジニアが多用する技術です。
ここまで取り上げた要素を合わせてオブジェクト指向の3原則・3要素と呼びます。
抽象化を含むこともある
今までお話しした3原則に共通の性質を抜き出す作業である抽象化を加えることもあります。抽象化とは、共通する性質や振る舞いを抜き出し、必要な情報だけを扱えるようにする考え方です。勇者・魔法使い・パラディンをすべて「キャラクター」として扱い、共通する行動だけをまとめるイメージです。
抽象化を行うとコード変更による影響力を調整しやすくなり、仮に問題が起きても特定の変数のみの影響に抑えることができます。カプセル化の一部として説明することも多いですが、独立して紹介している教材もあるので、簡単に紹介しました。
実務で活かせるオブジェクト指向のコーディングテクニック
コードを読むときはクラスの役割を特定する
基本の考え方を理解したところで、実務で活かす際の注意点をいくつか紹介します。まずはすでに組まれているソースコードを読むときの注意点です。
何千行もある複雑なコードを前にすると、誰でも迷子になります。まずは、ファイル名やクラス名を見て「何の設計図か」を確認してください。設計図の目的がわかると、全体の流れが見えやすくなります。
わかりやすい設計では、1つのクラスには1つの役割を割り当てていることが多いです。なので、クラスごとに何が書かれているか把握できればプログラムの全体像も把握しやすいでしょう。
丁寧な現場では、クラスの役割が日本語で解説されていることもあります。大枠の役割を頭に入れてから、細かい処理を読み進めていくとスムーズです。焦らずに、オブジェクトの関連性を紐解いていきましょう。
コードを書くときは1クラスに1つのことを書く
次に、コードを書くときの注意点です。コードを書く際は必ず1つのクラスに1つの要素のみを盛り込みましょう。
オブジェクト指向において重要な原則の一つに、単一責任の原則というものがあります。1つのクラスは一つの責務を持つべきだ、という意味です。今から作るクラスにどんな動作をさせたいか、どんな目的でクラスを作るのか具体的に考えてから作業をしましょう。
この1クラスに1つの要素という原則を守らずなんとなくコードを書き始めると、ほかのプログラムに転用しづらくなり、オブジェクト指向のメリットである再利用性が大幅に下がってしまいます。1つのクラスに様々な機能が盛り込まれると、修正が難しくなるだけでなく、プログラムが正常に機能しなくなる可能性が大きく上がります。必ずクラスに搭載したい機能を具体的に考えたうえでコーディングを始めましょう。
一歩リードしたい人向けのおすすめ書籍
なぜ,あなたはJavaでオブジェクト指向開発ができないのか
オブジェクト指向を使う言語の代表格であるJavaの習得を行いながら、オブジェクト指向の基礎から実践への橋渡しをしてくれる良書です。2004年発売のため、記載されているコードそのものは古めかしいものの、オブジェクト指向の考え方の根幹は現代にも生かせる内容です。Javaに限らず、他の言語にも応用できる内容なのもおすすめポイント。研修を受けたけれど、文法や考え方がイマイチピンと来ていない若手エンジニアに最適な1冊です。
関連記事
新わかりやすいJava オブジェクト指向徹底解説
こちらもJavaをベースにオブジェクト指向を学ぶ書籍ですが、前者と比べて図解が多く、視覚的に学べます。文字だけの説明で挫折しかけている人に適しています。基礎知識を体系的に整理し直す際に役立つ内容です。学生向けに書かれた本なので文章の解説もわかりやすく、例外処理やラムダ式など現場でもよく使う応用処理も学べる本です。
まとめ
オブジェクト指向は、システム開発をスムーズに進めるための便利な道具です。概念を一度理解すれば、様々なプログラミング言語の習得が簡単になります。この記事ではRPGのパーティーメンバーに例えてお話ししましたが、少しでもオブジェクト指向の考え方がわかれば幸いです。よりじっくり学びたい場合は、Javaなどオブジェクト指向を使った言語をベースにした書籍を読んでみるとより学びが深まるはずです。日々の実務や研修のストレスを減らして、エンジニアとしての自信に繋げていきましょう！
