私は単なるエンジニアであって学者や研究者ではないため、ここに書いてある内容は科学的に吟味されたものではありません。
が、普段の仕事の中で気付いた合理性のある内容だと思っています。
クラスの根本は、構造体(データ構造)とそれを扱う処理(関数orメソッド)を一体化させたものです。 次のリンクはSunのJava入門のページですが、そこにある図を参照して下さい。 What Is an Object?
Fieldsというのが構造体のことで、その周りをMethods(処理)が取り巻いています。この図は、クラスを基に生成されたオブジェクトの概念を書いたものですが、オブジェクトの設計図となるクラスの定義も同様な考え方です。
この図からも解るように、データ構造を持たないクラスはそもそもクラスとして機能しません。クラスの原理に反するからです。
ですが、データ構造を持たないクラスをJavaなどの言語では定義出来てしまうため、単なる関数を定義しただけのclassをクラスと勘違いしている設計者/プログラマーが大勢います。
責務という言葉を言い換えると「しなければならないこと」「出来なければならないこと」となります。クラスを利用する側から見るとそのクラスが何を出来るか(してくれるか)は確かに重要です。
ですがそれは使う側から見た場合であって、設計する人はそれだけではクラスを定義出来ません。一つ例を出します。
ジュース売りがしなければならないことは次のような事です。
つまり責務が決まったからと言ってそのモノまでは決められないのです。
これは当然で、「何が出来るのか」というのは処理の規定であってデータ構造、つまりそのモノの状態は関係無いからです。
Javaなどでは「Interface」として定義するのが責務です。Interfaceはメソッドを規定するだけで中身は実装者任せです。まさに、責務は決めるがモノは決めないという機能です。ちなみに私はInterfaceのことを責務ではなく「役割」と呼ぶようにしています。
クラスを設計する際、その基となるのは顧客からの要求です。要件と呼ばれます。この要件は、「xxxがしたい」「が出来るようになりたい」という実務処理の記述です。言ってしまえば役割を列挙したものです。
役割というのは上で書いたように処理に過ぎません。クラスとして必要なデータ構造はそれだけでは出て来ません。
そのため、オブジェクト指向に不慣れな設計者・実装者はその要件(処理)だけを頼りに開発してしまいます。データ構造を考えずに処理だけを追いかけてしまうのです。これが誤りの根本です。
が、普段の仕事の中で気付いた合理性のある内容だと思っています。
オブジェクト指向って?#
オブジェクト指向の説明として良く出てくるのが、- 隠蔽
- 継承
- 多態性
クラスを見つけるのがオブジェクト指向設計#
オブジェクト指向にはクラスが必要です。オブジェクト指向的に設計しようとすることはクラスを見つけることに他なりません。AクラスとBクラスが異なるクラスとして必要な理由は何?#
クラスを見つけるというのはつまりクラスを定義することですが、では、AクラスとBクラスという2つの異なるクラスが必要になる時の理由は何でしょうか?- 処理が異なる
- 責務が異なる
- データ構造が異なる
クラスの根本は、構造体(データ構造)とそれを扱う処理(関数orメソッド)を一体化させたものです。 次のリンクはSunのJava入門のページですが、そこにある図を参照して下さい。 What Is an Object?

Fieldsというのが構造体のことで、その周りをMethods(処理)が取り巻いています。この図は、クラスを基に生成されたオブジェクトの概念を書いたものですが、オブジェクトの設計図となるクラスの定義も同様な考え方です。
この図からも解るように、データ構造を持たないクラスはそもそもクラスとして機能しません。クラスの原理に反するからです。
ですが、データ構造を持たないクラスをJavaなどの言語では定義出来てしまうため、単なる関数を定義しただけのclassをクラスと勘違いしている設計者/プログラマーが大勢います。
責務がクラスを決めるのではないのか?#
クラスは「責務」によって定義されるといくつかの解説書には書いてありますが、これは誤りだと私は考えています。責務という言葉を言い換えると「しなければならないこと」「出来なければならないこと」となります。クラスを利用する側から見るとそのクラスが何を出来るか(してくれるか)は確かに重要です。
ですがそれは使う側から見た場合であって、設計する人はそれだけではクラスを定義出来ません。一つ例を出します。
「ジュース売り」という責務#
「ジュース売り」という責務を考えてみます。ジュース売りがしなければならないことは次のような事です。
- 注文を聞く
- 金額を伝える
- お金をもらう
- 品物とお釣りを渡す
ジュース売りを請け負えるモノとは?#
- 人間
- 自動販売機
つまり責務が決まったからと言ってそのモノまでは決められないのです。
これは当然で、「何が出来るのか」というのは処理の規定であってデータ構造、つまりそのモノの状態は関係無いからです。
Javaなどでは「Interface」として定義するのが責務です。Interfaceはメソッドを規定するだけで中身は実装者任せです。まさに、責務は決めるがモノは決めないという機能です。ちなみに私はInterfaceのことを責務ではなく「役割」と呼ぶようにしています。
みんななぜ間違うのか?#
世間ではクラスと思われているものが実は誤りである。なぜそうなってしまうのでしょうか?クラスを設計する際、その基となるのは顧客からの要求です。要件と呼ばれます。この要件は、「xxxがしたい」「が出来るようになりたい」という実務処理の記述です。言ってしまえば役割を列挙したものです。
役割というのは上で書いたように処理に過ぎません。クラスとして必要なデータ構造はそれだけでは出て来ません。
そのため、オブジェクト指向に不慣れな設計者・実装者はその要件(処理)だけを頼りに開発してしまいます。データ構造を考えずに処理だけを追いかけてしまうのです。これが誤りの根本です。
添付ファイルの追加
ログイン済のユーザのみが添付ファイルをアップロード出来ます。
添付ファイル一覧
Kind | Attachment Name | Size | Version | Date Modified | Author | Change note |
---|---|---|---|---|---|---|
png |
aggregation.png | 1.4 kB | 2 | 19-9-2011 00:08 | ytp | |
png |
aggregation2.png | 3.2 kB | 1 | 18-7-2011 01:13 | ytp | |
png |
aggregation3.png | 3.2 kB | 1 | 18-7-2011 01:13 | ytp | |
png |
association.png | 1.0 kB | 1 | 20-9-2011 00:04 | ytp | |
png |
composite.png | 1.4 kB | 1 | 18-7-2011 01:13 | ytp | |
png |
extend.png | 1.4 kB | 1 | 18-7-2011 01:13 | ytp | |
png |
generalize.png | 3.2 kB | 1 | 18-7-2011 02:28 | ytp | |
png |
implement.png | 1.9 kB | 1 | 18-7-2011 01:13 | ytp |
«
This particular version was published on 25-1-2011 00:33 by ytp.