●活動をメソッドにしない

01529/01529 VFF15672  T's-Neko         活動はメソッドにしない
( 6)   98/07/23 08:24  01510へのコメント

  いるか さん、こんばんは。T's-Neko です。(^o^)o

>ABC（アクティビティ・ベースド・コスティング：活動主義原価）みたいな
>捉え方をすれば、購入という業務機能は人というコストドライバを使うわけです。
>で、初めて購入プロセスが生成される。もちろん人だけじゃないけど。
>すると、人という資源（リソース）と、購入という業務機能は個別のもの
>なんです。これを一般的なOOの本を見ていると、くっつけるように
>見えるから（違っていたらゴメンなさいね）、話がおかしくなっちゃう。

これは、人によって異なるんじゃないかな。
・「人」が購入する。
・「購入」は人が行う。
コストは、購入から発生するものだから後者の考えが考えやすい。
でも、今日の人のスケジュールを知らせるとなると、
人が主体だから前者の方が考えやすい。
前者の方が OO らしく思えるけど、コストを測るシステムなら、
システムオブジェクトの購入メソッドになるはず。
でも、どっちが普遍的に正しいモデルかは判断できないでしょう。
だって、視点（使う人）によって変わるんだから。

でも、なまじ OO な人たちは、オブジェクトを活動主体(Subject)、
メソッドを活動(Event)にしたがるけど、
それは、Subject による分類という効果しかないんだよね。
処理対象(Object)の属性に get,set するメソッドだけの方が、
分類より強い所属という関係で、連想がしやすいから、
僕はいいモデルだと思うけどな。
あと、入出力が明確だし。
（活動はユースケースなんだよね）

>OOがどーたらこーたら、よりも、ビジネスアプリの世界に適用したいのであれば
>それぞれの領域でデフォのモデルから学ぶ方が、よっぽど確実。
>例えば、会計学なんて400年近い歴史があるわけですよ。それを元にじゃぁ
>OOならどうなるか、っていうのを小手先じゃなくて、きちんと正面から
>向き合った方がいいと思うんですよね。生産管理とかもそうだし。

もちろん先人の知恵を借りるのは当然だけど、それが適当な
モデルであるとは限らないと思います。
会計じゃないけど、物理ではオブジェクトを暗黙の了解にし、
属性ばかり扱っている傾向があります。そこで、自分なりに
オブジェクトを推測して勉強したことがあります。
（当時はオブジェクトと認識してなかったけどね）
やっぱり理論の世界は扱っている範囲が狭いですから、
暗黙の了解が多い。それを一般的なアプリに適用しようと
するなら、やっぱり何らかのモデルを再構築する
必要があると思います。

オブジェクト指向は、C++ でよくラッパークラスを
作るように、すでにあるものをラッピングするもの
だと思います。インターフェイスの理論とよく言われるし。
ですから、既にある理論自体に手を加えることはない。
多少解説的に別名を付けるぐらいは許して。
しかし、分類は、一歩間違えると衝突します。
たとえば、物理学の目次とオブジェクト指向物理学(^^;
の目次では、まったく異なります。
どちらの目次がいいのでしょうか。
僕は、物理学本来の目次がいいと思います。
目次（分類）は数の論理（要素が均等になるように分けること）
ですが、オブジェクト指向では、数の論理に合わないことが
多いですから。
しかし、オブジェクト指向は、その意味を語ってくれる。
つまり、内容を知りたいのならオブジェクト指向が適するの
うまく説明できないけど、表面は数の論理、一歩内容に踏み込むと
オブジェクト指向の世界が広がっている方がいい。
トップダウン（ユースケース的）に見れば数の論理、
ボトムアップにインターフェイスを定義するとオブジェクト
指向がいい。

とにかくオブジェクト指向は主役になっては
ならないことは確か。理論自体を
オブジェクト指向で変えてもいけない。
しかし、その間を補完するのがオブジェクト指向
の役割だと思う。それは、理論屋にとっては、
余分なことだし、ユーザにとっては
見えない部分。しかし、それが無いと有るのでは、
システム全体をピンからキリまで理解するとき、
多くの理論のつながりを理解するときに
差が出ると思う。

オブジェクト指向ってそんなもんだから、オブジェクトの
美しさより、機能的目的を達成することが最優先なんだけどね。
でも、お客は製品を要求するけど、生き残る企業は
コアコンピタンスを持っているところなんだよね。
そのインフラとして有力なのが
コンポーネント指向＋改良できる開発ツール
だね。

--- Neko.
access to Sage Plaisir! → http://www.ceres.dti.ne.jp/~m-toda/