添付ファイルの追加

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

添付ファイル一覧

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 23 changed 11 lines
!!責務をもう少し掘り下げてみる
責務というのは英語の'responsibility'の訳です。一般的には「責任」と訳します。\\
オブジェクト(またはクラス)が持つ責務として世間にある解説では、
#業務に必要な処理
#オブジェクトが持っている情報を通知すること
と書いてあります。\\
業務に必要な処理というのはジュース売りを例に取ると「注文を聞く」などがそれです。\\
「オブジェクトが持っている情報を通知すること」は内部にデータ構造がないと不可能なので、データ構造に依存するかのような説明に見えます。しかし、情報を通知するということはどんなオブジェクトにも必要な処理であって特定の業務とは無関係です。これをオブジェクトの「責務」と呼ぶのは勘違いだと私は考えます。オブジェクト指向においてオブジェクトに与えられている機能と言うべきでしょう。\\
責務というのはそのクラスがシステムの中で果たすべき業務的な役割のことであって、仕組みとして備わっている機能のことを呼ぶべきではないと言うのが私の考えです。
!!責務でクラスは決まらないもう一つの例
!!責務で考えると誤ったクラスが出てくる例
At line 27 added one line
\\
At line 31 added one line
\\
At line 35 added one line
\\
At line 44 changed one line
これをクラス図にすると次になります。\\
これを正しいクラス図にすると次になります。\\
At line 47 changed 2 lines
人事システムを設計する際に「ジムの会員」という役割を考慮する必要は現実にはないと思います。人事システムから見れば「人間=従業員」という構図は成り立つので、従業員をクラスとして定義することは正しいと思います。\\
しかしそれはシステム設計上の便宜性から来るものであることを忘れてはいけません。役割をクラスと勘違いした結果、上記のような誤った設計/実装を大変多く見かけます。\\
\\
人事システムを設計する際に「ジムの会員」という役割を考慮する必要は現実にはないと思います。人事システムから見れば「人間=従業員」という構図は成り立つので、そのシステムで従業員をクラスとして定義することは正しいと思います。\\
しかしそれはシステム設計上の便宜性から来るものであることを忘れてはいけません。役割をクラスと勘違いした結果の上記のような誤った設計/実装を大変多く見かけます。\\
At line 44 added 10 lines
!!責務をもう少し掘り下げてみる
責務というのは英語の'responsibility'の訳です。一般的には「責任」と訳します。\\
オブジェクト(またはクラス)が持つ責務として世間にある解説では、
#業務に必要な処理のこと
#オブジェクトが持っている情報を通知すること
と書いてあります。\\
業務に必要な処理というのはジュース売りを例に取ると「注文を聞く」などがそれです。これはその通りそのクラスが負うべき責務です。\\
「オブジェクトが持っている情報を通知すること」は内部にデータ構造がないと不可能なので、データ構造に依存するかのような説明に見えます。しかし、情報を通知するということはどんなオブジェクトにも必要な処理であって特定の業務とは無関係です。これをオブジェクトの責務と呼ぶのは勘違いだと私は考えます。オブジェクト指向においてオブジェクトに与えられている機能と言うべきでしょう。\\
責務というのはそのクラスがシステムの中で果たすべき業務的な役割のことであって、仕組みとして備わっている機能のことを呼ぶべきではないと言うのが私の考えです。責務はやはり処理を規定するだけでデータ構造には依存しないのです。
At line 52 changed one line
クラスを設計する際、その基となるのは顧客からの要求です。要件と呼ばれます。この要件は、「xxxがしたい」「mmmが出来るようになりたい」という実務処理の記述です。言ってしまえば役割を列挙したものです。\\
クラスを設計する際、その基となるのは顧客からの要求です。要件と呼ばれます。この要件は、「システムでxxxがしたい」「システムを使ってmmmが出来るようになりたい」という実務処理の記述です。つまりシステムの役割を列挙したものです。\\
At line 61 added 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