This is version 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

クラスを見つけるのがオブジェクト指向設計#

オブジェクト指向にはクラスが必要です。オブジェクト指向的に設計しようとすることはクラスを見つけることに他なりません。

AクラスとBクラスが異なるクラスとして必要な理由は何?#

クラスを見つけるというのはつまりクラスを定義することですが、では、AクラスとBクラスという2つの異なるクラスが必要になる時の理由は何でしょうか?

1. 処理が異なる
2. 責務が異なる
3. データ構造が異なる

正解は「データ構造が異なる」です。
クラスの根本は、データ構造(構造体)とそれを扱う処理(関数orメソッド)を一体化させたものです。 データ構造というのは属性(プロパティ)の集まりのことで、処理というのはそれらの属性の値を読んだり編集するために存在します。

次の図はSunのJava入門のページに書いてあるものです。What Is an Object?

Fieldsというのがデータ構造のことで、その周りを処理(Methods)が取り巻いています。この図は、クラスを基に生成されたオブジェクトの概念を書いたものですが、オブジェクトの設計図となるクラスの定義も同様な考え方です。
この図からも解るように、データ構造を持たないクラスはそもそもクラスとして機能しません。データ構造と処理の一体化というクラスの原理に反するからです。
ですが、データ構造を持たないクラスをJavaなどの言語では定義出来てしまうため、単なる関数を定義しただけのclassをクラスと勘違いしている設計者/プログラマーが大勢います。 public staticなメソッドのみのクラスがそれです※。ユーティリティクラスとも呼ばれます。
※正確に言うと、インスタンス変数にもクラス変数にもアクセスしないメソッドだけのクラスです。

クラスの成り立ち#

手続き型の時代から、オブジェクト指向のクラスがどのようにして生まれたのかを見ていきます。

手続き型の言語においても共通するデータ構造(構造体)をまず最初に決めます。

次に処理(関数)を作成し、処理と処理がデータ構造を受け渡す形で
ロジックを組み立てます。

ところが似たような処理があちこちに意図せず作成されてしまいます。

これを避けるために処理を共通化して共通関数を作成し、共通関数のみを
利用するような開発ルールを設けます。しかし仕組みとしての強制力がないため、
似たような関数が複数生まれる危険性は変わりません。

この危険性を取り除いたのがオブジェクト指向でのクラスです。データ構造が
共通関数を持つように仕組みとして強要します。

クラスの中核はデータ構造#

上記で見たように、クラスの最初に必要なのは共通化されたデータ構造です。
共通関数というものを開発したことのある人は解ると思いますが、関数(処理)を共通化するためには受け渡されるパラメータを共通化する必要があります。パラメータが複数ある場合、それらをひとかたまりにまとめるとデータ構造(構造体)になります。
つまり手続き型の言語においても、処理を共通化するためにはまず最初にデータ構造を共通化していたのです。
クラスにおいては、共通化されたデータ構造が処理も持てるようになっています。これがオブジェクト指向の原理です。

責務がクラスを決めるのではないのか?#

クラスは「責務」によって定義されるといくつかの解説書には書いてありますが、これは誤りだと私は考えています。誤りが言い過ぎだとしても、初学者に大きな誤解を与えています。
責務という言葉を言い換えると「しなければならないこと」「出来なければならないこと」となります。クラスを利用する側から見るとそのクラスが何を出来るか(してくれるか)は確かに重要です。
ですがそれは使う側から見た場合であって、設計する人はそれだけではクラスを定義出来ません。一つ例を出します。

「ジュース売り」という責務#

「ジュース売り」という責務を考えてみます。
ジュース売りがしなければならないことは次のような事です。

1. 注文を聞く
2. 金額を伝える
3. お金をもらう
4. 品物とお釣りを渡す

では、この責務を請け負えるモノは何が考えられるでしょうか?

ジュース売りを請け負えるモノとは?#

• 人間
• 自動販売機

ジュース売りを請け負えるモノとして少なくともこの2つが考えられます。将来的には「ロボット」も入ってくるかもしれません。
つまり責務が決まったからと言ってそのモノまでは決められないのです。
これは当然で、「何が出来るのか」というのは処理の規定であって、データ構造、つまりそのモノの状態は関係無いからです。
Javaなどでは「Interface」として定義するのが責務です。Interfaceはメソッドを規定するだけで中身は実装者任せです。まさに、「責務は決めるがモノは決めない」という機能です。ちなみに私はInterfaceのことを責務ではなく「役割」と呼ぶようにしています。

みんななぜ間違うのか?#

世間ではクラスと思われているものが実は誤りである。なぜそうなってしまうのでしょうか?
クラスを設計する際、その基となるのは顧客からの要求です。要件と呼ばれます。この要件は、「xxxがしたい」「mmmが出来るようになりたい」という実務処理の記述です。言ってしまえば役割を列挙したものです。
役割というのは上で書いたように処理に過ぎません。クラスとして必要なデータ構造はそれだけでは出て来ません。
そのため、オブジェクト指向に不慣れな設計者・実装者はその要件(処理)だけを頼りに開発してしまいます。データ構造を考えずに処理だけを追いかけてしまうのです。これが誤りの根本です。

まとめ#

• クラスを規定するのは処理ではなくデータ構造
• 役割(責務)をクラスにしてはいけない