ページ本文 ファイル添付 (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 4 changed one line
ですがそれはクラスを使う側から見た場合であって、設計する人はそれだけではクラスを定義出来ません。一つ例を出します。\\
しかしそれはクラスを使う側から見た場合であって、設計する人はそれだけではクラスを定義出来ません。一つ例を出します。\\
At line 19 changed one line
ジュースを買いたいという利用者側から見れば、それが人間だろうが自販機だろうが要件は満たされます。つまり責務が決まったからと言ってそのモノまでは決められないのです。\\
ジュースを買いたい購買者側から見れば、それが人間だろうが自販機だろうが要件は満たされます。つまり責務が決まったからと言ってそのモノまでは決められないのです。\\
At line 36 changed one line
ですがよく考えてみるとこれらの中でモノと呼べるのは人間だけです。従業員やジムの会員は、その人がその時その時に負っている役割に過ぎません。責務と言い換えてもいいでしょう。会社の中で負っているのが従業員という役割、ジムに行けば会員という役割に変わりますが、実体としては同じ人です。\\
しかしよく考えてみるとこれらの中でモノと呼べるのは人間だけです。従業員やジムの会員は、その人がその時その時に負っている役割に過ぎません。責務と言い換えてもいいでしょう。会社の中で負っているのが従業員という役割、ジムに行けば会員という役割に変わりますが、実体としては同じ人です。\\
At line 42 changed one line
しかしそれはシステム設計上の便宜性から来るものであることを忘れてはいけません。役割をクラスと勘違いした結果の上記のような誤った設計/実装を大変多く見かけます。\\
しかしそれはシステム設計上便宜的に行っている省略であることを忘れてはいけません。役割をクラスと勘違いした結果の上記のような誤った設計/実装を大変多く見かけます。\\
At line 50 changed one line
業務に必要な処理というのはジュース売りを例に取ると「注文を聞く」などがそれです。これはその通りそのクラスが負うべき責務です。\\
業務に必要な処理というのをジュース売りを例に取ると「注文を聞く」などがそれです。これはその通りそのクラスが負うべき責務です。\\
At line 72 changed one line
一方でこれらの伝票をRDBに保存したいような場合は、「RDBに読み書きする」というシステム的な役割も負います。
一方でこれらの伝票をRDBに保存したいような場合は、「RDBを読み書きする」というシステム的な役割も負います。
At line 78 changed one line
責務という言葉の定義にデータ構造への依存性を含むのかによってここでの議論は変わってきますが、含まない立場の私からは誤りに見えます。
「明細の一覧を扱う」・「RDBを読み書きする」それぞれの役割において変更が発生すれば、それぞれに対する修正が必要となるのは自明です。
At line 90 changed one line
次 [何をクラスにするのか]
!!コラム
責務という言葉の解釈によってこのページで書いたことは変わってくるとは思っています。つまり責務という意味の中に「データ構造を持つこと」を含むかどうかです。\\
データ構造を持つことはクラスの機能であって特定の目的のために定義したものではありません。クラスを決めるための責務にそのことを含めるのは私の感覚にはハマりません。\\
「責務」あるいは「責任」以外の意味がresponsibilityという英語にひょっとしてあるのかも知れません。そのモノの状態を含むというニュアンスです。私は英語ネイティブではないため判断付きません。仮にそうだとしても、責務や役割を規定することに頼らずにクラスを設計していくことが出来ます。\\
責務という言葉が一人歩きして、結局データ構造と処理を分離してしまっているシステムを多数見ています。「すること」に着目してしまっているからです。これは過去の手法への回帰にはなっても、進歩には決してならないと感じています。\\
プログラムの開発手法は次のように変遷してきたと思います。
*手続き型
*構造化
*データ中心主義
*オブジェクト指向
この遷移は歴史的検証をしたものではありませんが、ざっくりとしてはこうではないでしょうか。\\
データ中心主義の時代を経てオブジェクト指向が生まれてきたのに、データ中心で設計するケースが世間では未だに少ないのは非常に残念です。\\
「することに着目せずに」クラスを見つけることは出来ます。そのことを次ページ以降に書きたいと思います。\\
次: [何をクラスにするのか]
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