最近、改めてオブジェクト指向の説明というものを見直すことがあったのですが、出てきた結論としては「イマドキのオブジェクト指向」という形で再編集しても良いのではないかと。
先週の丸山先生レクチャーシリーズ2007-2008 第3回「SOAの現在」で発表した「メッセージ指向によるシステム開発の変化の兆し ~遍在するメッセージ指向~」は、その表れ。ウルの河村さんと話しているときに盛り上がって、そのまま形にしたものです。
では、「イマドキのオブジェクト指向」とは何か。それはメッセージ指向という解釈です。オブジェクト指向は「メッセージによる処理の分割」であり、「分離された処理をオブジェクトと呼ぶ」と定義します。これまではオブジェクト指向とは「オブジェクトによる処理の分離」であったわけです。
背景
現在、ソフトウェアを作る時に重要なのは「処理をいかに分離し、作業を分担するのか」ということです。これはプロジェクトの生死を分けるといっても過言ではありません。
大きな原因はメンバーのスキルが一定でないことでしょう。システム内が細かくレイヤー化されているためプレゼンテーション層、ビジネスロジック層、パーシステンス層、インテグレーション層と、専門家が出現せざるをえません。当然、使われるフレームワークやプロダクトによっても変わってきます。もちろん能力のばらつきも大きい。ご存知の通りソフトウェア開発は極端な労働集約産業であり、個人の能力が大きく成果物に影響する。
次にドメインやサービスというようなメタレベルの解釈でシステムを分割することが良いプラクティスであること。システムは現実世界の情報をモデル化していきます。顧客の要求が多様になることで、このモデルが非常に複雑になっています。そのためモデルをグループ化し、きれいに保つのも非常に重要なことです。最近好きな言い方だと「オブジェクト間の関係性の濃淡」を調整するわけです。なお、ソースコードレベルではパッケージ(名前空間)分けによる管理が行われるところです。
処理の統合戦略
「いかに分離するか」というので重要なのが統合戦略です。というか、処理をスマートに統合できる仕掛けが増えてきたことで分離のさせ方が多様になった、という説明が正しいはず。オブジェクト同士を統合させる手法として、ぱっと考えただけ以下のようなものが思いつきます。
1.生成
2.ファクトリー(Dependency Lookup)
3.DI(Dependency Injection)
4.イベント(Pub/Sub、Listener)
生成は「相手の存在そのものを知っている関係」です。相手の実装クラスを知っており、newして利用します。
ファクトリーは「相手のIDだけを知っている関係」です。相手を特定するためのキーを知っており、ファクトリーから取得して利用します。
DIは「相手のIDを外部化した関係」です。インターフェースは知っているものの、相手が誰かは設定によって与えられます。本人は相手を特定するIDを知りません。
イベントは「相手は知らず、イベントだけを知っている関係」です。相手を特定するIDすら知りません。イベントを上げる、あるいは受け取ることによって処理を行います。ですから、誰がイベントを受け取るか、誰がイベントを上げたのかは知りません。
同期/非同期、送信のみ/送受信といった区分けで細かく類型化できるはずです。コールバックは非同期の送受信。MOMのようなキューによる処理は非同期の送信のみ。
オブジェクトよりも関係性のデザインが重要
これらの手法を組み合わせることで処理の統合方針をデザインするのがアーキテクトの役目でしょう。オブジェクト同士の関係を決め、適切な手法で分けるのです。一般的には3DIと1生成の組み合わせが多いはずです。2ファクトリーは場合によって処理を振り分けたい場合、あるいは自分自身の生成タイミングにDIコンテナが口をはさめない場合に有効な方法です(例えばServletとか)。
4イベントはインテグレーション層ではSOA、プレゼンテーション層ではリッチクライアントやAjaxでは良く使われます。まだまだビジネスロジック層では一般的な手法ではありませんが、Spring IntegrationやSeamに見られるようにPub/Subやキューを使った処理は、どんどん取り入れられていくはずです。
ここで振り返ると、現在のシステムで重要なのは「オブジェクトのデザイン」よりも「関係性のデザイン」であることが分かるのではないでしょうか。もちろんオブジェクトのデザインは変わらず重要です。ですが、関係性のデザインをうまく使うことで、よりシステム開発が進歩する気がします。
その点でオブジェクト指向という名称は視野を狭くしてしまうのです。UMLも関係性のデザインについては非常に弱い。
というわけで、これからオブジェクト指向を学ぶ人は、まずメッセージや関係性から学んではどうかと思います。具体的なところは、これから深めていこうと思います。

コメント (5)
ご存知かと思いますが、統合戦略に関しては、
http://www.amazon.co.jp//dp/0321200683
この本がありますよね。MuleSourceのCTOはこの本のパターンを実装したと言っていましたよ。
統合パターンはESBに任せて、現在の製品進化の最終目標である「ポリシーベースでのリソースのダイナミックの割り当て」までに対応できるノウハウ・経験を積まないといけないなぁと丸レク3回目では感じました。
投稿者: さやべえ | 2008年01月28日 11:32
日時: 2008年01月28日 11:32
あくまで私見ですが、そもそもSOAとオブジェクト指向をそこまできちんと整理、統合して考える必要ってあるんですかね。現実てきなんでしょうか。
あえてコメントしてみました。失礼。
投稿者: Sun Fujii | 2008年01月28日 15:35
日時: 2008年01月28日 15:35
さやべえさん、情報ありがとうございます。知りませんでした。が、Amazonへのリンクが変みたいです。再Up希望です。ポリシーベースというアイデアは面白いですね。なんにせよダイナミックに構成が変わるというアイデアは、今後の延長線上にあると思います。
Sun Fujiiさん。うーん、あえて整理してみた、という感じです。オブジェクトに縛られないでねーみたいな感じでよいとは思いますがね。
投稿者: yusuke | 2008年01月29日 22:45
日時: 2008年01月29日 22:45
スラッシュが余分でした
http://www.amazon.co.jp/dp/0321200683
投稿者: さやべえ | 2008年01月30日 21:39
日時: 2008年01月30日 21:39
さやべえさん、ありがとうございます。読んでみます。
投稿者: yusuke | 2008年01月31日 02:57
日時: 2008年01月31日 02:57