ページ本文 ファイル添付 (5) ページ情報

添付ファイルの追加

ログイン済のユーザのみが添付ファイルをアップロード出来ます。

添付ファイル一覧

Kind Attachment Name Size Version Date Modified Author Change note
png
 class_history01.png 10.0 kB 1 27-1-2011 00:07 ytp
png
 class_history02.png 16.5 kB 1 27-1-2011 00:19 ytp
png
 class_history03.png 38.4 kB 1 27-1-2011 00:19 ytp
png
 class_history04.png 20.1 kB 1 27-1-2011 00:19 ytp
png
 class_history05.png 25.0 kB 1 27-1-2011 00:19 ytp

This page (revision-22) was last changed on 18-6-2014 13:36 by ytp

This page was created on 26-1-2011 01:44 by ytp

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 44 removed 28 lines
[責務はクラスではない]
!!責務がクラスを決めるのではないのか?
クラスは「責務」によって定義されるといくつかの解説書には書いてありますが、これは誤りだと私は考えています。誤りが言い過ぎだとしても、初学者に大きな誤解を与えています。\\
責務という言葉を言い換えると「しなければならないこと」「出来なければならないこと」となります。クラスを利用する側から見るとそのクラスが何を出来るか(してくれるか)は確かに重要です。\\
ですがそれは使う側から見た場合であって、設計する人はそれだけではクラスを定義出来ません。一つ例を出します。\\
!!「ジュース売り」という責務
「ジュース売り」という責務を考えてみます。\\
ジュース売りがしなければならないことは次のような事です。
#注文を聞く
#金額を伝える
#お金をもらう
#品物とお釣りを渡す
では、この責務を請け負えるモノは何が考えられるでしょうか?\\
!!ジュース売りを請け負えるモノとは?
*人間
*自動販売機
ジュース売りを請け負えるモノとして少なくともこの2つが考えられます。将来的には「ロボット」も入ってくるかもしれません。\\
つまり責務が決まったからと言ってそのモノまでは決められないのです。\\
これは当然で、「何が出来るのか」というのは処理の規定であって、データ構造、つまりそのモノの状態は関係無いからです。\\
Javaなどでは「Interface」として定義するのが責務です。Interfaceはメソッドを規定するだけで中身は実装者任せです。まさに、「責務は決めるがモノは決めない」という機能です。ちなみに私はInterfaceのことを責務ではなく「役割」と呼ぶようにしています。
!!みんななぜ間違うのか?
世間ではクラスと思われているものが実は誤りである。なぜそうなってしまうのでしょうか?\\
クラスを設計する際、その基となるのは顧客からの要求です。要件と呼ばれます。この要件は、「xxxがしたい」「mmmが出来るようになりたい」という実務処理の記述です。言ってしまえば役割を列挙したものです。\\
役割というのは上で書いたように処理に過ぎません。クラスとして必要なデータ構造はそれだけでは出て来ません。\\
そのため、オブジェクト指向に不慣れな設計者・実装者はその要件(処理)だけを頼りに開発してしまいます。データ構造を考えずに処理だけを追いかけてしまうのです。これが誤りの根本です。
At line 74 changed one line
*役割(責務)をクラスにしてはいけない
!!コラム
「クラスとはデータ構造のこと」と社内の若手プログラマー達に教えています。\\
正確に言うと「データ構造と処理を一体化したもの」なんですが、クラスを見分ける際に最初にやることはデータ構造を考えることなので上記のように繰り返し言っています。
にもかかわらず彼らは処理に目が行ってしまい、手続き型の考えにすぐなってしまいます。\\
これが人間の本能なのかは判りませんが、プログラマーはそれに陥りやすいと思って設計者は設計する必要があるようです。
つまり曖昧な言葉による表現は避け、きちんとしたクラス図を書いて依頼し、プログラマー任せの製造は避けるべきだと考えています。\\
またプログラマー達がコードのみで考える状態から脱却するため、早いうちからクラス図の読み書きを修得するよう指導することも重要です。
Version Date Modified Size Author Changes ... Change note
22 18-6-2014 13:36 2.05 kB ytp to previous
21 23-5-2014 17:47 2.047 kB ytp to previous | to last
« This page (revision-22) was last changed on 18-6-2014 13:36 by ytp