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

添付ファイルの追加

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

添付ファイル一覧

Kind Attachment Name Size Version Date Modified Author Change note
png
 employee.png 0.7 kB 1 27-1-2011 22:46 ytp
png
 human.png 3.7 kB 1 27-1-2011 22:46 ytp
png
 human_interface.png 6.1 kB 3 12-2-2011 01:42 ytp
png
 inherit_human.png 4.9 kB 2 20-2-2011 15:30 ytp
png
 jymmember.png 0.8 kB 1 27-1-2011 22:46 ytp
png
 twointerface.png 9.5 kB 3 28-1-2011 01:18 ytp

This page (revision-30) was last changed on 29-8-2016 00:23 by ytp

This page was created on 27-1-2011 21:48 by ytp

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 3 changed one line
責務という言葉を言い換えると「しなければならないこと」「出来なければならないこと」となります。クラスを利用する側から見るとそのクラスが何を出来るか(してくれるか)は確かに重要です。\\
責務という言葉を言い換えると
*しなければならないこと
*出来なければならないこと
となります。クラスを利用する側から見るとそのクラスが何を出来るか(してくれるか)は確かに重要です。\\
At line 21 changed one line
Javaなどでは「Interface」として定義するのが責務です。Interfaceはメソッドを規定するだけで中身は実装者任せです。まさに、「責務は決めるがモノは決めない」という機能です。ちなみに私はInterfaceのことを責務ではなく「役割」と呼ぶようにしています。このページでは責務と役割を同義として書いています。
Javaなどでは「Interface」として定義するのが責務です。Interfaceはメソッドを規定するだけで中身は実装者任せです。まさに、「責務は決めるがモノは決めない」という機能です。ちなみに私は
*Interfaceのことを__役割__と呼ぶ
ようにしています。このページでは責務と役割を同義として書いています。
At line 30 changed one line
これらをある1人の人の視点から見るとクラス図は次のようになります。
これらをある1人の人の視点から見るとクラス図は次のようになります。\\
At line 32 changed 2 lines
継承を使ってオブジェクト指向っぽい設計図になりました。\\
果たして本当にそうでしょうか? 次の図で考えてみます。\\
継承を使ってオブジェクト指向っぽい設計図になったように見えますが、果たして本当にそうでしょうか?\\
\\
次の図で考えてみます。\\
At line 42 changed 2 lines
人事システムを設計する際に「ジムの会員」という役割を考慮する必要は現実にはないと思います。人事システムから見れば「人間=従業員」という構図は成り立つので、そのシステムで従業員をクラスとして定義することは正しいと思います。\\
しかしそれはシステム設計上便宜的に行っている省略であることを忘れてはいけません。役割をクラスと勘違いした結果の上記のような誤った設計/実装を大変多く見かけます。\\
人事システムを設計する際に「ジムの会員」という役割を考慮する必要は現実にはないと思います。人事システムから見れば「人間=従業員」という構図は成り立つので、従業員をクラスとして定義することは人事システム設計上正しいと思います。\\
しかしそれはシステム設計上便宜的に行っている省略であることを忘れてはいけません。役割(責務)をクラスと勘違いした結果の上記のような誤った設計/実装を大変多く見かけます。\\
At line 47 changed one line
オブジェクト(またはクラス)が持つ責務として世間で見かける解説では、
オブジェクト(またはクラス)が持つ責務として世間で見かける解説には、
At line 51 changed one line
業務に必要な処理というのをジュース売りを例に取ると「注文を聞く」などがそれです。これはその通りそのクラスが負うべき責務です。\\
ジュース売りの例の中で業務に必要な処理というのは「注文を聞く」などです。これはその通りそのクラスが負うべき責務です。しかしそのクラス(もの)が何であるか、つまりデータ構造を規定できないことは上記で書いたとおりです。\\
At line 69 added one line
At line 73 changed one line
一方でこれらの伝票をRDBに保存したいような場合は、「RDBを読み書きする」というシステム的な役割も負います。
一方で、これらの伝票をRDBに保存したいような場合は「RDBを読み書きする」というシステム的な役割も負います。
At line 80 changed 2 lines
この例においてRDBを読み書きする役割を別のクラスに分けてしまうとそのクラスはデータを持たない処理だけのクラスになってしまい、「データ構造としての伝票クラス」と「RDBを読み書きする処理のクラス」の2つに結局分割されることになり、データ構造と処理を一体化させるためのクラスという原理から外れてしまいます。\\
ただし、同じ伝票クラスの情報を「テキストファイルに出力したい」という新たな要件が出てくると新たなメソッドを伝票クラスに実装する必要がまた出て来ます。その次はネットワークに出力したい等も考えられ、出力媒体が出てくるたびに処理を追加する必要が出て来ます。この問題への対応は別ページで書きます。\\
この例においてRDBを読み書きする役割を別のクラスに分けてしまうとそのクラスはデータを持たない処理だけのクラスになってしまい、
#データ構造としての伝票クラス
#RDBを読み書きする処理のクラス
の2つに結局分割されることになり、データ構造と処理を一体化させるためのクラスという原理から外れてしまいます。\\
ただし、同じ伝票クラスの情報を「テキストファイルにも出力したい」という新たな要件が出てくると新たなメソッドを伝票クラスに実装する必要がまた出て来ます。その次はネットワークに出力したい等も考えられ、出力媒体が出てくるたびに処理を追加する必要が出て来ます。この問題への対応は別ページで書きます。\\
At line 85 changed one line
クラスを設計する際、その基となるのは顧客からの要求です。要件と呼ばれます。この要件は、「システムでxxxがしたい」「システムを使ってmmmが出来るようになりたい」という実務処理の記述です。裏返すと、「システムはxxxが出来なければならない」「システムはmmmというサービスを提供しなければならない」となります。つまりシステムの役割・責務を列挙したものです。\\
クラスを設計する際、その基となるのは顧客からの要求です。要件と呼ばれます。この要件は、
*システムでxxxがしたい
*システムを使ってmmmが出来るようになりたい
という実務処理の記述です。裏返すと、
*システムはxxxが出来なければならない
*システムはmmmというサービスを提供しなければならない
となります。つまりシステムの役割・責務を列挙したものです。\\
At line 87 changed one line
しかし、オブジェクト指向に不慣れな設計者・実装者はその要件(処理)だけを頼りに開発してしまいます。データ構造を考えずに処理だけを追いかけてしまうのです。これが誤りの根本です。
しかし、オブジェクト指向に不慣れな設計者・実装者はその要件(処理)だけを頼りに開発してしまいます。
*データ構造を考えずに処理だけを追いかけてしまう
のです。これが誤りの根本です。
At line 95 changed one line
責務という言葉の解釈によってこのページで書いたことは変わってくるとは思っています。つまり責務という意味の中に「データ構造を持つこと」を含むかどうかです。\\
責務という言葉の解釈によってこのページで書いたことは変わってくるとは思っています。つまり責務という意味の中に
*データ構造を持つことを含むかどうか
です。\\
At line 98 changed one line
一方で、「責務を全うするためにはデータ構造が必要となる」とは言えます。しかしだからと言って、責務を考えた結果データ構造が導き出せるとは私の経験上思えません。\\
一方で、
*責務を全うするためにはデータ構造が必要となる
とは言えます。しかしだからと言って、責務を考えた結果だけでデータ構造を導き出せるとは私の経験上思えません。\\
At line 101 changed 4 lines
*手続き型
*構造化
*データ中心主義
*オブジェクト指向
#手続き型
#構造化
#データ中心主義
#オブジェクト指向
At line 108 changed one line
次: [何をクラスにするのか]
次: [クラスにするもの]
Version Date Modified Size Author Changes ... Change note
30 29-8-2016 00:23 4.983 kB ytp to previous
29 23-5-2014 17:40 4.934 kB ytp to previous | to last
28 07-1-2012 03:49 4.938 kB ytp to previous | to last
27 03-1-2012 23:56 4.919 kB ytp to previous | to last
26 06-3-2011 00:06 4.901 kB ytp to previous | to last
25 06-3-2011 00:02 4.895 kB ytp to previous | to last
24 23-2-2011 01:21 4.888 kB ytp to previous | to last 何をクラスにするのか ==> クラスにするもの
23 20-2-2011 15:33 4.89 kB ytp to previous | to last
22 20-2-2011 15:29 4.89 kB ytp to previous | to last
21 12-2-2011 01:52 4.888 kB ytp to previous | to last
« This page (revision-30) was last changed on 29-8-2016 00:23 by ytp