●オブジェクトと操作の分類

02019/02019 VFF15672  T's-Neko         オブジェクトと操作の分類
(16)   98/02/27 10:10  02001へのコメント

  なべＱ さん、こんばんは。T's-Neko です。(^o^)o

>で過酷な仕事です。こういうときに概念的な新しいエンティティをうまく
>導入することによっていかにモデルがきれいにまとまることか。
>
>たとえば、ひとつひとつの石油製品はいくつかの作り方があって、それぞ
>れの作り方毎に使用できる設備の組合わせがいくつかあったりします。こ
>れをユーザーの言う通りにナイーブにモデル化すると異常に複雑なシロモ
>ノとなります。そこで、作り方のパターンである「工程系列」というエン
>ティティと、設備の組合わせを示す「設備系列」というエンティティを識
>別子を工夫して親子関係で導入することによってモデルがきれいにまとま
>りました。この説明だけ聞くと何ということもないように思えるでしょう
>が、これらのエンティティは年季のいった現場の担当者でさえも想像した
>ことのなかった「概念」上の情報のまとまりなのです。(ちなみにエンテ
>ィティの名称をそのようなものにしようと発案したのはユーザーでした。
>とても的確だと思います）

工程系列と設備系列。
じつに優れた分類である。
しかし、なぜ、優れた分類であるといえるのだろうか？

  特殊情報処理調査機関 Sage Plaisir [saju plezi]
  日夜極秘調査任務を請け負うエージェント達が活動している。
  なお、この調査報告は（おそらく）事実である

工程系列と設備系列といった分類について、
Neko 教授は次ようにコメントしている。

  非常にいいグループ分けだと思います。
  オブジェクト指向でも、設備系列に相当する「オブジェクト」と、
  工程系列に相当する「操作」を区別しないと、しっかりとした
  トップダウン設計はできません。僕が設計する場合、何より始めに
  その区別をします。


「オブジェクト」と「操作」

オブジェクトは、人、もの、マシン、道具、といったもののこと、
操作は、集計する、計算する、動かすといった行為のことである。
これらの分類に注目すると、ある人間の頭脳に秘められた法則が見つかる。
英語の５文型を挙げてみよう。
  ○ SV,SVC,SVO,SVOO,SVOC
  × S,SO,SC,V,VV
上段は５文型、下段はそれ以外の S,V,C,O の組み合わせである。
ここにある法則があることに気づかないだろうか。

それは、５文型のどのパターンにも、「オブジェクト」に相当する
S,C,O と「操作」に相当する V の両方が必ず存在しているのである。
つまり、これらの情報が無い限り、人間の頭脳は、意味のあることと
認識できないのである。（バーン）

これを踏まえれば、プログラムの解読に次のようなヒントが得られると
考えられる。

たとえば、A さんが B さんのプログラムを解読しているとしよう。
A さんは、ある要素 a とある要素 b がポイントだなと思ったとする。
しかし、それがたまたまオブジェクトだけだったり、操作だけだったり
すると、A さんの頭脳は「だからどうした？」状態と認識してしまう。
これが、「苦しい」状態である。
そこで、A さんは、まだ、情報（要素）が足らないと判断し、
幸運にもオブジェクトと操作がそろったとしよう。
すると、A さんの頭脳は「なるほど」状態になり、
A10神経が刺激され非常に快適な気分になるのである。

では、どうすれば、苦しい状態にならずに済むのであろうか。
一般的に、クラスや構造体がオブジェクト、
関数やマクロが操作に分類される。
これは、だれも疑うことはないだろう。
しかし、この分類には重大な罠が潜んでいるのだ。（ばーん）

（ＣＭ）
ｿｰｽとﾄﾞｷｭﾒﾝﾄの統合 Knowledge Take! 無償配布中
Sage Plaisir - http://www.ceres.dti.ne.jp/~m-toda/
毎月更新してるよ。よろしくね。


一般的に、クラスや構造体がオブジェクト、
関数やマクロが操作に分類される。
しかし、この分類には重大な罠が潜んでいるのだった。

  たとえば、スレッドは、Java でもMFC でもクラスになっていますね。
  でも、これらは操作に分類した方がいいと思います。スレッドは、
  あるプロセスなのですが、たいてい何か操作的な目的を持って
  いるものです。
  また、ウィンドウ・ハンドルを取得する関数がありますね。
  これは、関連オブジェクトに分類した方がいいでしょうね。
  このように、一概にクラスはオブジェクト、関数は操作と
  決め付けない方がいいでしょうね。(Neko教授)

もう少し具体的な例で説明してみよう。
毎年１度だけ実行される決算プログラムがある。
これは MFC などのクラスライブラリで、アプリケーションという
クラスになっている。しかし、「決算する」という言葉が
あるように、これは操作としか考えられない。
また、総支出額を計算する関数があったとしよう。
関数は操作と考えるのがごく一般的な考えであるが、
総支出額という属性、つまりオブジェクトと考えた方が、
より自然な考え方であろう。

つまり、これらの事実から次の結論が導かれる。
 ソースコードだけでは、オブジェクトか操作かといった情報が無い

すなわち、ソースコードだけからすべてを解読しようとするのが、
苦しくなるというのはどんなに優れたプログラマでさえ陥ってしまう、
ごく自然なことだったのだ。



なるほど、これも、ソースだけでは苦しいという、１つの原因ですね。

こういう分類は、非常に理解を助けるのだが、アプリ全体から
見たときと、内部の詳細を見たときでは、ある同じコードの部分でも
その分類が大きく変化するからな。だから、時にはオブジェクトを
操作と認識を変えたりする柔軟さが必要だな。

じゃぁ、そんな分類をドキュメントに決め付けるように書いてしまっ
ていいんですか？

その件ですけど、たとえば、アプリ全体から見たとき、といった
同じケースなら、たとえ誰が分類しても同じような結果になると
ある調査機関から報告されています。ですから、ドキュメントで
分類を決めてしまっても構わないでしょう。

そうかぁ。やっぱりドキュメントって大切だよな。
そういえば、このまえのプログラム、出来てるか。

ばっちりですよ。このとおりドキュメントも。

なんだこれは、実に機械的なドキュメントだな。
さては、ドキュメント作成ツールでも使ったな。
これだけじゃわからん。やりなおし。

--- Agent Neko.




つ、つかれた...