| At line 9 changed 3 lines |
| 正解は「データ構造が異なる」です。\\ |
| クラスの根本は、データ構造(構造体)とそれを扱う処理(関数orメソッド)を一体化させたものです。 |
| データ構造というのは属性(プロパティ)の集まりのことで、処理というのはそれらの属性の値を読んだり編集するために存在します。\\ |
| 正解は「__3.データ構造が異なる__」です。\\ |
| クラスの根本は、 |
| *データ構造(構造体)とそれを扱う処理(関数orメソッド)を一体化させたもの |
| です。\\ |
| データ構造というのは属性(プロパティ)の集まりのことで、それら属性の値を読んだり編集したりするために処理は存在します。\\ |
| At line 13 changed one line |
| 次の図はSunのJava入門のページに書いてあるものです。[What Is an Object?|http://download.oracle.com/javase/tutorial/java/concepts/object.html]\\ |
| 次の図はOracleのJava入門のページに書いてあるものです。出典: [What Is an Object?|http://download.oracle.com/javase/tutorial/java/concepts/object.html]\\ |
| At line 17 changed 4 lines |
| この図からも解るように、データ構造を持たないクラスはそもそもクラスとして機能しません。データ構造と処理の一体化というクラスの原理に反するからです。\\ |
| ですが、データ構造を持たないクラスをJavaなどの言語では定義出来てしまうため、単なる関数を定義しただけのclassをクラスと勘違いしている設計者/プログラマーが大勢います。 |
| public staticなメソッドのみのクラスがそれです%%sup ※/%。ユーティリティクラスとも呼ばれます。\\ |
| ※正確に言うと、インスタンス変数にもクラス変数にもアクセスしないメソッドだけのクラスです。 |
| この図からも解るように、 |
| *データ構造を持たないクラスはそもそもクラスとして機能しない |
| のです。データ構造と処理の一体化というクラスの原理に反するからです。\\ |
|
| At line 22 changed 2 lines |
| オブジェクト指向のクラスというのがどのようにして生まれたのかを見ていきます。\\ |
| {{{手続き型の言語においてもまず最初に共通するデータ構造(構造体)を決めます。}}} |
| 手続き型の時代から、オブジェクト指向のクラスがどのようにして生まれたのかを見ていきます。\\ |
| {{{手続き型の言語においても共通するデータ構造(構造体)を最初に決めます。}}} |
| At line 31 changed one line |
| 利用するような開発ルールを設けます。しかし仕組みとしての強制力がないため |
| 利用するような開発ルールを設けます。しかし仕組みとしての強制力がないため、 |
| At line 38 changed 4 lines |
| !!責務がクラスを決めるのではないのか? |
| クラスは「責務」によって定義されるといくつかの解説書には書いてありますが、これは誤りだと私は考えています。誤りが言い過ぎだとしても、初学者に大きな誤解を与えています。\\ |
| 責務という言葉を言い換えると「しなければならないこと」「出来なければならないこと」となります。クラスを利用する側から見るとそのクラスが何を出来るか(してくれるか)は確かに重要です。\\ |
| ですがそれは使う側から見た場合であって、設計する人はそれだけではクラスを定義出来ません。一つ例を出します。\\ |
| !!クラスの中核はデータ構造 |
| 上記で見たように、クラスの最初に必要なのは |
| *共通化されたデータ構造 |
| です。\\ |
| 共通関数というものを開発したことのある人は解ると思いますが、 |
| *関数(処理)を共通化するためには受け渡されるパラメータをまず共通化する |
| 必要があります。パラメータが複数ある場合、それらをひとかたまりにまとめるとデータ構造(構造体)になります。\\ |
| つまり手続き型の言語においても、 |
| *処理を共通化する前にデータ構造を共通化 |
| していたのです。クラスにおいては、 |
| *共通化されたデータ構造が処理も持てる |
| ようになっています。 |
| *そのクラスを基にした個体(インスタンスあるいはオブジェクト)をメモリ上に複数生成 |
| 出来ます。これがオブジェクト指向の原理です。 |
| At line 43 removed 22 lines |
| !!「ジュース売り」という責務 |
| 「ジュース売り」という責務を考えてみます。\\ |
| ジュース売りがしなければならないことは次のような事です。 |
| #注文を聞く |
| #金額を伝える |
| #お金をもらう |
| #品物とお釣りを渡す |
| では、この責務を請け負えるモノは何が考えられるでしょうか?\\ |
| !!ジュース売りを請け負えるモノとは? |
| *人間 |
| *自動販売機 |
| ジュース売りを請け負えるモノとして少なくともこの2つが考えられます。将来的には「ロボット」も入ってくるかもしれません。\\ |
| つまり責務が決まったからと言ってそのモノまでは決められないのです。\\ |
| これは当然で、「何が出来るのか」というのは処理の規定であって、データ構造、つまりそのモノの状態は関係無いからです。\\ |
| Javaなどでは「Interface」として定義するのが責務です。Interfaceはメソッドを規定するだけで中身は実装者任せです。まさに、「責務は決めるがモノは決めない」という機能です。ちなみに私はInterfaceのことを責務ではなく「役割」と呼ぶようにしています。 |
|
| !!みんななぜ間違うのか? |
| 世間ではクラスと思われているものが実は誤りである。なぜそうなってしまうのでしょうか?\\ |
| クラスを設計する際、その基となるのは顧客からの要求です。要件と呼ばれます。この要件は、「xxxがしたい」「mmmが出来るようになりたい」という実務処理の記述です。言ってしまえば役割を列挙したものです。\\ |
| 役割というのは上で書いたように処理に過ぎません。クラスとして必要なデータ構造はそれだけでは出て来ません。\\ |
| そのため、オブジェクト指向に不慣れな設計者・実装者はその要件(処理)だけを頼りに開発してしまいます。データ構造を考えずに処理だけを追いかけてしまうのです。これが誤りの根本です。 |
|
| At line 67 changed one line |
| *役割(責務)をクラスにしてはいけない |
|
| !!コラム |
| 「クラスとはデータ構造のこと」と社内の若手プログラマー達に教えています。\\ |
| 正確に言うと「データ構造と処理を一体化したもの」なんですが、クラスを見分ける際に最初にやることはデータ構造を考えることなので上記のように繰り返し言っています。 |
| にもかかわらず彼らは処理に目が行ってしまい、手続き型の考えにすぐなってしまいます。\\ |
| これが人間の本能なのかは判りませんが、プログラマーはそれに陥りやすいと思って設計者は設計する必要があるようです。 |
| つまり曖昧な言葉による表現は避け、きちんとしたクラス図を書いて依頼し、プログラマー任せの製造は避けるべきだと考えています。\\ |
| またプログラマー達がコードのみで考える状態から脱却するため、早いうちからクラス図の読み書きを修得するよう指導することも重要です。\\ |
| \\ |
| 次: [責務はクラスではない] |
