柔軟性、構造安定性のデザイン: 非同期メッセージモデル、OOPとFunctional Programming

作者 Sadek Drobi , 翻訳者 編集部 投稿日 2007年11月17日

セクション

エンタープライズ・アーキテクチャ,

設計/アーキテクチャ,

デベロップメント

トピック

メッセージング ,

Webサービス ,

OOP ,

Haskell ,

Erlang ,

エンタープライズアーキテクチャ ,

方法論 ,

Functional Programming ,

SOA ,

Object Oriented Design ,

モデリング ,

Architecture ,

プログラミング ,

Parallel Programming ,

設計 ,

パフォーマンス&スケーラビリティ

共有 |

”尋ねないで頼みなさい”Pragmatic Programmersによると、オブジェクト指向のプログラミングにおいては”データを尋ねるよりもむしろオブジェクトに頼む”ほうが好ましい(source)ということだ。Michael Feathers氏は特に、より大規模なシステムにおいてはこれが”非常に役立つアドバイス”と捉えている。

戻り値は作業を呼び出し元に押し戻す。作業をしてメッセージをコラボレーターに送っても十分ではないのです。何かがあなたに戻ってくるのを待ち、そして多分もっと作業しなくてはなりません。値を戻さないほうが良いのです。

Feathers氏によると、テスト駆動の開発結果内の模造品を使用すると結果としてこの種のアーキテクチャをもたらす。

オブジェクトに何かをするよう頼んでそれが完了したかどうか尋ねるよりも、むしろオブジェクトに何かをするように伝えそのコラボレーターに何が起こるか見たほうが良いのです。それらは少しワークフローに似たようなものです。新たな条件下ではデザインの影響が少ないのです。そして筋も通るのです。それぞれのオブジェクトはひとつのことを成し遂げそのサクセッサーに警告する責任があるのです。

これを超えて考えることも可能である。Feather氏はもし戻ってくる戻り値がないのならば、同期のメッセージを送るよりもむしろ非同期のメッセージを送 るほうが効率的であるかもしれないことを論じている。H.S.Lahman氏は、実のところそれを”ビヘイビアは非同期と想定される”(source)オブジェクト指向のアーキテクチャにおいて論じてきた。今日のOOPモデルはしかしながら、オブジェクト指向のプログラミング言語において、”メッセージとメソッドは分離されていない”ので同期型なのである。これによって保持性だけでなく構造安定性も向上可能な正確なOOA/Dモデルの建築が困難になるのである。

Michael Feathers氏が説明したようにこれはErlangモデルを位置づける。

Erlangの背景にある考えは、もしあなたがたくさんのプロセスを作るのが可能でそれらがステートを共有しないということを保証できれば、より強固なシステ ムの開発が可能だということだ。それぞれのプロセスがメッセージを受け取り仕事をし、他のプロセスにメッセージを送るのだ。

Feathers氏によると、”尋ねないで頼みなさい”のプログラミングモデルは、”両方ともデータがそれに沿って流れる比較的ステートレスな基質を持っているように見える"のだが、”機能的なプログラミングのほとんど正反対”であるそうだ。　

機能的なプログラミングの一番純粋な形態においては、絶対に頼むことはしないだろう。その代わりに尋ねるのだ。そして怠惰な評価がある時はシステムはあなたの質問に答える際に必要な分だけするのである。

Ralph Johnson氏が、Erlangは”中核において00”ということを指摘したに事に関してFeathers氏が強調したように、間違いなくErlangは純粋に機能的な言語として考慮されない。

あなたの意見ではどちらのステートレスモデルが今日の適応性と強固性の問題に対処するのに適しているだろうか？Erlangの非同期メッセージモデルかもしくは純機能的プログラミングアプローチ、さあどちらだろうか？（例：Haskell）

原文はこちらです：http://www.infoq.com/news/2007/11/asynchronous-oop-and-fp