<< 状態遷移(プロトコルモデル)の実装 【パターン】 | main | RDRA リレーションシップ駆動分析から、いよいよ実装へ >>

オブジェクト指向とは、モノ指向であり、目的指向である

今、採用支援システムと、国際物流システムという、異なったドメインの初期のモデリングを、掛け持ちでやっている。

採用支援システムのほうは、どちらかというと、「人」と「人」との連係をうまく支援するためのシステム。
「仕事」がそのつなぎ役のオブジェクト。

国際物流システムのほうは、さまざまな外部システムとの「システム間連係」が、重要なテーマ。
「貨物」という実体を、情報化して、関連システム間で、効果的に情報を交換するためのシステム。

2つの案件は、ドメインも、システムの性格もかなり異なるので、頭の切り替えがたいへんだけど、やってみると、モデリングや設計の考え方や基本テクニックを、整理する、良いチャンスだと感じるようになってきた。

個々の部分最適のテクニックではなく、より、一般的に使える考え方や、テクニックを習得するよいチャンス。
自分のモデリングスキルを、向上できる機会に恵まれた感じ。

オブジェクト指向


あらためて、オブジェクト指向的な発想を重視すべきだと、思うようになった。

それも、「そもそも」的な意味でのオブジェクト指向。

オブジェクトは、「的」というのが本来の意味だと思っている。(なにかを投げつける、その対象物)
実体のある「対象物」という意味を重視すると、「モノ」。
実体がなくても、目指す対象、という意味を膨らませると、(概念的な)「目的」。

システムのモデリングや設計という文脈にあてはめると、 how より what、 手段より目的、を重視することが、オブジェクト指向ということ。

ソフトウエア開発は、全体でみれば、「どうやって実現するか」という、how 指向であり、手段指向の世界だと思う。
本質的には、オブジェクト指向ではない。

だからこそ、how より what、 手段より目的を、重視する「オブジェクト指向」に価値がでてくる。

ITは、how と 手段の集合体。それを活用するためには、what や、目的から出発するのが良い結果を産む。

IT に限らず、how より what、手段より目的を重視せよ、というのは、ビジネススキルという一般的な意味でも、とっても大切なはず。

ビジネス一般でも、how 中心、手段中心ということが、多いのが実情。IT の世界では、それが、さらに強くて、弊害が、はっきりあらわれている。 できあがってみたら、目的とはかけ離れたシステム、事業に価値をもたらさないシステムが、なんと多いことか。

事業にとって価値のあるシステム開発するなら、what や 目的を「指向」する、というより、what や 目的で、how/手段を「駆動」する、という、もっと積極的な考え方がよさそう。

オブジェクト指向を進めて、オブジェクト駆動

「モノ」を定義する。
「目的」を考える。

これを駆動力にして、いろろな how / 手段 を引きだしから、引っ張り出してきて、組み立てていくのが、ソフトウェア開発のやり方として、成功パターンになりそう。

まずは宣言


how より、 what ということは、コードのレベルで考えれば、XML, SQL , アノテーションなど、「宣言」型の記述方法が中心になる。

UML などの「図」法も、宣言型に近い。 シーケンス図とか振る舞いモデルの図も、振る舞いを「宣言」する感じ。

文章や、プログラミング言語は、手続き型。

手続きスタイルの、ソフトウェア開発がなくなるわけではないけど、大きな方向としては、「手続き」型より、「宣言」型で、考えたり、記述することが増えてきている。

what 駆動、目的駆動という視点からは、 what や 目的を「宣言」できれば、開発完了、になるのが理想。

少なくとも、まずは、 what / 目的 の記述に注力する。
そこがある程度、固まってきてから、はじめて、 how / 手段 の検討に入る、ということ。

逆にいえば、 how や 手段 が不明だったり、できそうかどうか、とかは無視して、まずは、 what / 目的を明らかにしてみるべし、ということ。

what 駆動、目的駆動でやるには、 how や 手段の知識は、ノイズだったり、余計なバイアスだったり、発想の足かせになる。

技術者として、 how や手段の知識は、財産。その財産から、いったん離れて、 what 駆動、目的駆動に注力するのが、良いモデリング・設計の基本だし、また、それが奥義なんだと思う。

オートマトン


「オブジェクト」は、本来は、「自律的」という意味は、なかった。(今でも、一般的な言葉としては、「自律」という意味はないはず)。

ソフトウェアの技術体系の基本モデルのひとつに「オートマトン」がある。
プログラミングとか、情報システムの根底には、この「オートマトン」モデルがある。

オートマトンは「自律的に動く」ことが、その基本の発想(定義?)。

オブジェクト指向を「プログラミング」という文脈でとらえた時、あたりまえのように「オートマトン」「自律的に反応する」という発想になる。

オブジェクト指向プログラミング(OOP) は、自律的に反応する「what」に注目する、という「オブジェクト指向」+「オートマトン」という合成物。

「オブジェクト指向」そのものには、「自律的に動く」という意味合いは、ない。

オブジェクト指向で、分析・設計するということは、いったんは、「オートマトン」、つまりプログラミングのモデルから離れて、「モノ」の定義、「目的」の定義を、重視するのが良いモデリング・設計のコツなんだろうと、思い始めている。

オブジェクト指向の分析の結果を、現在のオブジェクト指向系といわれる言語で実装するのが良いかどうかは別の問題。

私の感覚では、 XML は、宣言型で、 what 指向なので、オブジェクト指向風の言語。
Java は、アセンブラ、Cという由緒正しい(?)、マシン操作の手続きを記述するための言語。

Java のように、汎用的な言語の場合には、書き方によって、手続き重視でもかけるし、宣言重視でもかける。

ドメインモデルを、Java で実装する場合、Bean Validation のアノテーションなどを使いながら、かなり、宣言的に書けるようにはなってきている。

アグリゲートのルート、というような構造の宣言も、 XML マッピング用のアノテーションを導入すると、記述できる。

自然な書き方かどうかは、かなり疑問だけど、使えるものを使う、という発想で、開発言語として、Java を使いつつ、ドメインモデルを宣言的( what 指向 ) に実装しようと、いろいろやってみている。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
 123456
78910111213
14151617181920
21222324252627
28293031   
<< May 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM