第十三回-02 何故クラスを使うのか?


手続き型プログラミングとの違い

第十三回-01でテレビクラスを実装し、main 関数から利用してみた。
あの中にオブジェクト指向プログラミングのエッセンスがある程度詰まっていると言える。

その意義を理解するため、先程の例を手続き型プログラミングの手法で書いてみよう。 以下の通りである。

#include <iostream>

int main(int argc, char* argv[])
{
	// 電源、チャンネル、ボリューム変数の宣言
	int power, channel, volume;

	// 電源、チャンネル、ボリュームの初期化
	power = 0;
	channel = 1;
	volume = 0;

	// 値のセット
	power = 1; // 電源オン
	channel = 8;
	volume = 10;

	// 状態の表示
	if(power == 1){
		std::cout << "電源はオンです。";
		std::cout << "チャンネルは" << channel << "です。";
		std::cout << "ボリュームは" << volume << "です。\n";
	}else{
		std::cout << "電源はオフです。\n";
	}

	return 0;
}

多少プログラム自体を簡略化して記述したが、内容は理解できるだろうか。
単に変数を3つ宣言し、値を代入したあと値を表示したというだけの内容で、「それがどうした」というプログラムになっている。

この手続き型プログラミングと比べると、クラスを用いたプログラミングの特徴として、まず、以下が挙げられる。 手続き型プログラミングの場合は、電源、チャンネル、ボリュームはそれぞれ単なる変数であるので、
それぞれがテレビの構成要素であることが伝わりにくい。それに比べるとクラスを用いた場合は
それら3つがまとまっているので意味が明確になっている。

次にクラスを用いたプログラムの特徴には以下がある。 まず、上の例では、テレビの電源をオンにする処理は「power = 1;」に該当するが、 これは単に変数に1を格納しているだけであり、
「電源をオンにしている」という意味が伝わりにくい。

一方、クラスを用いた例での「tv.setPower(1);」は、関数名をわかりやすくつけたこととも相まって「電源に1をセットしている」ことがわかりやすい。
(さらに露骨に PowerOn() とか PowerOff() というメンバ関数を作ればさらにわかりやすかったかもしれない)

このように、変数を宣言したり、変数に値を格納する、というだけの処理であっても、
手続き型プログラミングとオブジェクト指向プログラミングは考え方が全く異なり、
オブジェクト指向プログラミングではいかに意味を明確にするか、に注意が払われていることがわかる。


データ隠蔽 (カプセル化)

さらに、オブジェクト指向プログラミングの特徴を探っていこう。

まず、テレビクラスを利用する main 関数を再掲しておこう。
Visual Studio 2019 では、「#include "stdafx.h"」は存在しない、「_tmain(int argc, _TCHAR* argv[]」ではなく「main()」である、などの違いがあるが気にしなくとも良い。



ここで一つ気づいて欲しいことがある。
テレビ関数には、データメンバとして power、channel、volume があったはずだが、main 関数には全く登場していないことである。
(これを「main 関数からアクセスされていない」、という言い方をする)

その替わりに利用されているのが、setPower、setChannel、setVolume といったメンバ関数である。
これらのことを「テレビクラスが提供するインターフェイス」、という言い方もする。
また、今回のプログラムではそもそも main 関数から直接 power、channel、volume という変数には直接アクセスできない仕組みにしている。

このことは重要なので図で表しておこう。下図のように、Television クラスの変数 (インスタンス) tv があったとき、
その内部にある変数 power、channel、volume にはクラス利用者にアクセスさせず、
setXXX 関数 (setter という) や getXXX 関数 (getter という) を用いてアクセスさせる
、というのが基本的な考え方である。



現実にテレビを持っている方は多いだろうが、実際のテレビでも電源、チャンネル、ボリュームはリモコンや前面パネルでアクセスするだけで、
テレビの中でそれらがどう実現されているかはわからない
人がほとんどだろう。
それと同じことをプログラミングでも行っているわけである。

変数に直接アクセスさせない理由は、変数があらゆる場所から編集可能だと、思いもかけないバグの温床になる可能性があるからである。
そのため、setter や getter を使うよう、変数のアクセスに制限をかけている、というわけである。
これをデータ隠蔽 (情報隠蔽、カプセル化などとも) という。

ここで、オブジェクト指向プログラミングにおいて、「誰がプログラミングするのか」に関する前提を紹介しておこう。
下の表のように、クラスを開発するクラス開発者と、クラスを利用するクラス利用者は異なる、と考えるとデータ隠蔽の考え方は理解しやすい。

Television.h クラス開発者が記述する。クラス開発者はメンバ関数のみをクラス利用者に公開し、
内部にあるデータは隠蔽する。
Television.cpp
TVProject.cpp (main 関数など) クラス利用者が記述する。クラス利用者はクラス開発者と同じとは限らない。
開発者から公開されたメンバ関数を活用し、必要な機能を実装する。

つまり、上の図と合わせて考えると、クラス開発者はクラスの内部の動作の実装に注力し、
クラス利用者は公開されたメンバ関数の活用に注力する、というわけである。

もちろん、このような講義や、個人で作る小さなプログラムの場合は 一人の人がクラス開発者とクラス利用者の一人二役をこなすのだが、
その場合もクラス開発者になるのかとクラス利用者になるのかで頭を切替える、ということである。

また、GUI アプリケーションのプログラミングなどで、Microsoft などが提供するライブラリを持ちいてプログラミングする場合、
皆さんはクラス利用者の役割を演ずることになる。

さて、本ページで登場した「オブジェクト指向プログラミングを用いるメリットを再掲しておくと以下の通り。 上の2つ「意味が明確になる」というのは保守性が高まる (メンテナンスしやすくなる) という言い方もできるかもしれない。

なお、今回紹介できるのはここまでであるが、「データ隠蔽」の他に、「継承」、「多態性」を加えて
オブジェクト指向の三大要素、と呼ぶことがあることを付記しておく。

さて、もちろんこのようなメリットがある半面、前ページで見たようにオブジェクト指向プログラミングでは記述量が増えるというデメリットはある。
しかし、大規模なプログラミングでは、記述量の増大というデメリットよりも保守性と安全性を高めるというメリットの方が大きくなるだろう



←第十三回-01 テレビクラスを作ってみよう第十三回-03 ドット演算子とアロー演算子→

非情報系学生のための C/C++ 入門に戻る