●DOAとプロセス指向とオブジェクト指向

02528/02529 VFF15672  T's-Neko         DOAとプロセス指向とオブジェクト指向
(16)   98/08/28 13:40  02524へのコメント

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

>して、そのモデル中の「ローズオブジェクト」と「ジャックオブジェク
>ト」を人間に置き換えようとした場合、彼らが利用すべき道具であるプ
>ログラム群がそのモデルから自動生成できるのか、できないとしても、
>どの程度プログラミングのための仕様情報を抽き出せるのか。そこらへ
>んに興味があります。コストの問題を度外視すれば、それが可能ならビ
>ジネスアプリでもＯＯは利用できるはずなのですが...

仕事をしている人間は、役割を持ったプロセスと性質が一致します。
たとえば、注文していた荷物が届いたから倉庫の適切な場所に
運ぶ、ということは、荷物が届いたというイベントから始まる
イベントドリブンのプログラムでモデル化することができます。

それを（機能的）オブジェクトとしてもいいのですが、
１つ上のレイヤのシステムオブジェクトのメソッド操作に
しても構いません。

どちらにせよ、イベントハンドラ（プログラム）には、
すでに、荷物オブジェクト、倉庫オブジェクト（ファイル、
テーブル、ベルトコンベア（倉庫自動搬入機）でも可）の
クラス（概念）がある必要があります。
新人なら倉庫の位置を教えないと仕事できませんし、
もしかすると倉庫って何か教えないといけないかもしれません。
それが、ローズオブジェクトが倉庫オブジェクトへの参照を
持っていたり、倉庫搬入関数が、倉庫オブジェクトへの
参照を引数に持ったりします。

ただ、プロセス指向、もとい関数的プログラミングになると、
サブ処理をする関数がグローバルに参照できるので、
引数に倉庫オブジェクトを指定するような面倒なことが
無いので便利の思えるかもしれません。
しかし、それは、倉庫に関するデータをグローバルに
参照している限り、容易にプログラミングできるわけで、
もし、倉庫が２種類あるとすると、倉庫番号などの
データが引数として必要になってきます。

サブ処理は、倉庫搬入関数モジュールのローカルサブ関数に
なったり、ローズ（搬入係）オブジェクトのプライベート
関数になったりします。どちらにせよ、彼らが利用すべき
道具であるプログラム群が近くにあります。
このように機能的なことであれば、オブジェクトでも
関数（プロセス）でも構いません。
一般に、システムの外部に公開するのは、関数になります。

しかし、プロセスを管理する必要が生じた場合は、
オブジェクトである方が適当です。
たとえば、ローズ・搬入リーダーが、倉庫管理の
スティーブと、力持ちのブルートの手を借りないと
できない仕事が来たとします。
倉庫管理関係では、荷物搬入チェック関数と、
空き場所検索関数があるとします。
ブルートには、「手で運べ！」と「フォークリフトを
使いまわせ！」と「休んでいいぞ」の命令が
できるとします。（これらも関数とする）

いま、スティーブの担当と、ブルートの担当を
分けましたが、関数が多くなると、このような
担当分けが重要になってきます。
ブルートに荷物搬入チェックをしてもいいのですが、
チェックに関する知識（データ）が無いのでできません。
（スティーブに聞けばできますけど非効率です）
スティーブに荷物搬入チェックをさせれば、
（メンバ変数として）知識や経験から
すぐに仕事の内容を理解し（プログラミングでき）
仕事を完了します。このように、データの集合と
関数の集合という組み合わせで、関連が深い傾向が
あるので、クラスとしてまとめた方がいいのです。

さらに、話を進めると、スティーブはいつも
倉庫管理ばかりしてるわけではありません。
ブルートもたまにはデスクワークもします。
つまり、荷物搬入という「場」では、
倉庫管理の「役割」を持ったスティーブと、
力持ちの「役」を持ったブルートを
インターフェイスとして、ローズ・リーダーは
命令（プログラムの実行）をしています。
リーダーは、会社の代表として搬入作業という
イベントハンドラ関数を公開し、受け付けます。

>どの程度プログラミングのための仕様情報を抽き出せるのか。

ローズ・リーダーにとっては、荷物搬入という「場」
（クラスまたは関数）から、倉庫管理の「役割」
インターフェイスと、力持ちの「役割」インターフェイス
を操るだけですから、その詳細は知る必要がありません。

でも、ローズ・リーダーにとっては、いったいスティーブは
何やってるんだろうか興味のあるところです。
それは、インターフェイス関数の内容を見ればわかること。
そこには、スティーブの知識（メンバ変数）を駆使して
作業が進められていることがわかります。

でも、きっとローズさんは、それを知って大変だなぁ、
と同情しても、自分じゃしたくねーな、スティーブに
任せよう、と思うでしょうし、そんな知識（データ）を
持つ（与える）ために勉強したくないな、スティーブが
知ってるからいいや、と思うでしょうね。

何でも知っていて、仕事をバリバリこなすスーパーマンが
いればいいですけど、普通の人間は「役割」という
社会が生み出した概念が与えられていて、必要な
知識と作業内容（手に職）が分担されています。
リーダーは、担当者に仕事を分担しているだけです。
こういった組織をシミュレーションするための手法が
オブジェクト指向です。


しかし、オブジェクト指向だけでは、次のケースがおきます。

ブルートに、この荷物をここへ。この荷物は、
1cm 間隔で並べて。と細かすぎる指示を出すと
「俺にいちいち指図するな！馬鹿にするな！」となります。
一人前の役割が与えられないからです。
「そんなに言うんなら自分でやれ」と言われます。
というわけで、「とにかく、荷物を倉庫に入れておけ」
という指示になります。ほとんどの場合、
オブジェクトの最終状態（出力）が出てきます。
なぜなら、処理は、終了すると特定の静的状態（データ構造）に
なりますから。
そうなると、プロセスよりも、データが主導(DOA)になります。


ただ、作業報告となると、「荷物を入れました」だけでは、
「なぜ、スティーブとブルートが必要なのだ？」と言われます。
そこでは、リーダ自身のプロセスを説明して、
この場面でブルートを使いました、と説明が要ります。
場合によっては、ブルートは何してんだ、という話にも
なるかもしれませんが、それはレビューアの性格に左右されるので、
報告書にはそれを考慮しないといけません。
システムは、その報告を事前に行うので、仕様書には、
プロセスが書かれている必要があり、プロセス指向になります。

--- Neko.