清野です。
> わたしやみつじさんが言うところのアプローチに過ぎないと感じたからです
その通りだと思います。
アプローチの違いに過ぎないと思います。
> 物ではなく事であるというところに拘らず
ですが、そのアプローチにあえて拘ってみたいのです。
なぜなら、ゴールは同じでも、ゴールにたどり着くまでの道の険しさが違うかも
知れないからです。
アプローチにより道の険しさが違うとしたら、できるだけ楽をしたいので、
どのようなアプローチがどの種のアプリケーションに向いているのか？
アプリケーションの種類によって、より簡単なアプローチはなにか？
と考えてみます。
かなり乱暴ですが、アプリケーションを制御系、業務系とわけてみます。
・制御系のアプリケーション
組み込み系などです。
関わったことはありませんがプラント制御などもこちらだと思います。
携帯電話、最近流行のハイテク白物家電、未来から来たネコ型ロボットなども
こちらだと思います。
＃スイッチ、カーナビゲーションなどSadManさんが例に挙げられていました
これらは、オブジェクトが自立的に振舞う傾向の強いアプリケーションだと
考えます。
自立的に振舞う「現実の物体」を見つけることが肝要ですので、
いわゆるオブジェクト指向のクラス抽出の王道である、
先のSadManさんも書かれているような、
次のアプローチが簡単で効率も良いと思います。
＃これを否定するつもりは毛頭ありません。
＞オブジェクト指向としてモデルを考えた場合、
＞OOPの説明に良く出てくるようにまず現実の物体そのものをオブジェクトと考え
＞次に物体ではないけれどもいろいろな概念をあたかも物体のように考えてモデル
化します
これを「物体/概念アプローチ」と呼んでみます。
・業務系のアプリケーション
ビジネスアプリケーションという表現もありました。
会計ソフト、生産管理システム、販売管理システムなどです。
基本的にシステムは自立的な振る舞いはしません。
システムは人が何かをするのをじっと待っているのみです。
人が行う業務の事実を記録するという傾向の強いアプリケーションです。
つまり、人が何かをする、その記録としてクラスが存在します。
よって、現実の物体を追いかけるよりも、人が何かをするきっかけである
イベントを追いかけるほうが、簡単で効率が良いのではないか、
と考えているのです。
先のSadManさんの表現をいじらせていただくと、次のようなアプローチです。
＞オブジェクト指向としてモデルを考えた場合、
＞OOPの説明に良く出てくるのとは反対に、
＞まず物体ではないけれどもいろいろな概念（業務）を
＞あたかも物体（オブジェクト）のように考えて
＞次に現実の物体そのものをオブジェクトと考えモデル化します
これを「概念/物体アプローチ」と呼んでみます。
ここでクラス抽出のアプローチにおける「オブジェクト指向の解釈」が
二通り想定できます。
1つ目。
「物体/概念アプローチ」、「概念/物体アプローチ」のいずれもオブジェクト指向
といえる。
この場合、私の分析手法は「概念/物体アプローチ」なので、
オブジェクト指向です。
2つ目。
オブジェクト指向とは「物体/概念アプローチ」をさすのであり、
「概念/物体アプローチ」はオブジェクト指向ではない。
この場合、私の分析手法は「概念/物体アプローチ」なので、
オブジェクト指向ではありません。
SadManさんは次のように書かれています。
> 結果的に清野さんの辿り付く先はオブジェクト指向になると思います
上記の「オブジェクト指向」の解釈により変わると思います。
私は現時点では前者であると理解しました。
したがって、私の分析手法「概念/物体アプローチ」はオブジェクト指向である、
ということでSadManさんのご指摘の通りだと思います。
今回の議論の前には、一般的に後者が常識のようである、という前提で
文章を書いていました。
だとすれば私は分析手法はオブジェクト指向ではなくても良い、
というものでした。
前提がおかしかったようです。わたしの勘違いです。
このあたりの私の主張を みつじさん が簡潔にまとめてくださいました。
＞みつじさん
> 清野さんとしては、上記を理解した上で、特に「業務の事実」に
> 注目してクラスを導出する手法を提案したいということですね。
> やっと理解できました。
その通りです。
たった2行で説明できることになぜ私はこんなに苦労するのか。。
文才のなさをあらためて痛感しました。
−−
清野博之