| ||
| ||
|
ロジックとコンポーネントの分離
一方アーキテクチャの観点からすると，まず前述のコンポーネントをどう生かすかが第一のカギだ。コンポーネントはソフトウェア部品の配布単位であり，プロジェクト管理や保守の単位である。機能の再利用単位として作り出されたもので，言語レベルのオブジェクトよりユーザーの要件に近い。従って，本質的に言語には依存しない。
コンポーネント・モデルは，適切な実行環境を構築できなければならない。具体的には，コンポーネントを管理する実行環境の構成定義がしやすいことや，宣言的に実行制御できるようコンポーネントに属性を与えられるなどだ。実装レベルのコンポーネント・モデルには，CORBA（Common Object Request Broker Architecture），COM（Component Object Model），EJB（Enterprise JavaBeans）などがある。また仕様レベルでは「UML for EDOC」なども存在する。
コンポーネント・モデルは技術とシステムの複雑化に合わせて今後も発展するだろう。それにつれて，抽象化とブラックボックス化も進行する。一般的な開発の大半は機械的な作業となる。コンポーネント・モデルが提供するソフトウェア部品やプログラミング・モデルに従って構成を決めて，属性を宣言するだけで作業がほとんど完了してしまうからだ。また，開発ツールの進歩により実装支援クラスを含む複数ソースファイル，属性設定，テストケース，ドキュメントの作成などを一カ所で一括管理できる。結果として開発作業はさらに機械的になる。
この段階では，概念や内部的な動作の理解より，生産性向上が優先される。結果としてソフトウェア工学に基づく品質改善が軽視されやすい。例えばRobert Martin氏の依存関係の原理では，クラスの適切な依存関係を提示している（図4[拡大表示]）。非循環的な依存関係，不安定なクラスから安定なクラスへの依存関係，具象クラスから抽象クラスへの依存関係を適正としている。これ自体はごく当たり前の原理だ。だが実際には，表面的有効性にとらわれてこの原理に従わない多くのデザインが存在している。こういったあたりに自由度が残されているのも，オブジェクト指向の本質的な課題なのかもしれない。
また，コンポーネントは前述のような目的で作り出されたモデルなので，本来はロジックとコンポーネントを分離するのが適切である。しかし，実際にはこの原則を混乱させる実行環境は少なくない。例えばJ2EEやCOM＋では，実装言語でコンポーネントのクラスを定義するとき，インタフェースに属性定義を加えて，トランザクションやセキュリティ処理を宣言的に設定できる（リスト1[拡大表示]）。従来のトランザクション・モニターを利用したプログラミング・モデルに比べ，格段に高い生産性と柔軟性が得られる。
しかしトランザクションやセキュリティの要件は，本来業務プロセスや，概念レベルの仕様で決定されるべきものだ。つまり要件が定義されるのは実装レベルのコンポーネントではないはずである。拡張性や保守性など非機能要件（機能外の要件），コンポーネント・モデルや実行環境の制約により直接対応付けられないことがある。この点ではコンポーネントに要件を定義するのは必ずしも正しいとは言えない。単純なプロパティ設定で済むような開発スタイルでも，概念レベルから実装レベルへ進む際に正しく要件をシステムの仕様として定義し直さなければならない理由の一つである。
プロセス中心かデータ中心アプローチか
データの取り扱いという点でも，オブジェクト指向を適用するときに陥りやすい問題がある。オブジェクト指向では振る舞いと状態を一体として扱い，その状態をオブジェクト内部に隠蔽する。ただその結果として，状態を表現するデータ構造をオブジェクトの機能ごとに定義してしまいがちだ。これは場合によっては大きな誤りとなる。
例えば，企業システムにおいては顧客情報を用いて多くの業務を処理する。受注業務では受注した取引先情報として顧客情報を利用する。技術支援業務では，問題解決の依頼者のアクセス先などに顧客情報が使われる。これらの業務システムがそれぞれ単独で動作していれば，データ設計の問題は表面化しない。しかし，いわゆるEAI（Enterprise Application Integration）を実施して，受注した取引先にスムーズに購入商品の技術支援を実施できるよう連動させようとすると問題が発覚する。一般に企業システムでは，個々のシステムがバラバラの時期に構築されている。類似の情報であっても必要な項目が違うため，システムごとにデータ構造が異なる。この例では受注オブジェクトに隠蔽した顧客情報と，技術支援業務の問い合わせオブジェクトに隠蔽した顧客情報である。
企業システムでは，商品や部品，顧客などのマスターデータにしても，売り上げや受注，出荷などのトランザクションデータにしても，本来は再利用頻度の高い情報のはずである。しかし現実には個々の業務システムごとにデータを定義している。従ってデータを管理するデータベースのスキーマ定義も共通化されず，業務システムごとにデータの孤島ができる（図5[拡大表示]）。これ自体はオブジェクト指向の本来的な欠点ではないが，設計の自由度が大きすぎる弊害と言えなくもない。
EAIの問題を教訓とすれば，特定業務プロセスの機能に依存させず，企業システム全体や，サプライチェーン全体の観点からオブジェクトのデータモデルを定義して，各システムで共通化することを考慮すべきだ。企業システムの複雑度を減らし，保守性や品質が改善するからである。別の見方をすると，アプリケーション機能を実現するアーキテクチャと情報モデルの再利用性や経営戦略的な価値を考慮するデータのアーキテクチャを分離することを意味する。アーキテクチャを見る「視点」が違うので，「視点の分離（separation of concerns）」と呼ばれる考え方に基づいている（詳細は後述）。視点の分離は設計におけるカップリングを減らす代表的手法である。従来，データの共通化（正確に言えばデータの意味＝概念の一元管理）といえば，データ中心アプローチの専売特許のように思われてきた。しかし，オブジェクトの振る舞いと連携を定義するプロセス中心アプローチの設計手法においてもデータの共通化は重要であり，両者を適切に組み合わせる手法が求められる。特に最近は，疎結合なシステム連携やサービス指向アーキテクチャ（SOA）が提唱されており，この考え方は重要性を増している＊1。
オブジェクトの粒度は大きくなる傾向に
オブジェクト指向における究極の課題は，何をオブジェクトとして定義すべきかが明確でない点だ。この問題には一般的な解がない。経験的に導かれた指針があるだけである。例えば，システムを使う場面（ユースケース）に現れる動詞や名詞を手がかりにする方法や，役割や状態に着目する方法である。こうしてまず概念レベルのオブジェクトを発見し，識別しておく。実装レベルではこれらの概念レベルのオブジェクトに実装上の要件や性能，保守性，再利用性などを加味して，クラスを設計する。このとき凝集度が高くカップリングが低い単位で実装クラスを作成する。この考え方はDijkstra氏の構造化プログラミングの原理と同じである。ただ現実問題として，採用するコンポーネント・モデル，配布などの制約条件も考慮しなければならない。
企業の業務システムでは，粒度の大きいオブジェクトも使われる。ビジネス・コンポーネントあるいはビジネス・エンティティと呼ばれる単位だ。将来，いわゆるビジネス・フレームワークが主流となれば，アプリケーション・サーバーの実行単位が現在のコンポーネントから，さらに粒度が大きいビジネス・エンティティに替わるだろう。生産性と実行効率の向上が期待されるからだ。
再利用より保守性を重視せよ
企業システムではオブジェクト指向でよく言われる再利用より保守性が重視される。企業システムはその稼働ライフサイクルが長いからである。ライフサイクルの間に発生する業務要件や技術の変化に迅速かつ安価に対応しなければならない。そのためには資源を有効活用する再利用性よりも，保守性が重視される。
保守性の向上には，変更の影響範囲を局所化することが重要である。そのためには疎結合をうまく取り入れ，オブジェクト間のカップリングを減らす。疎結合を実現するには，(1)変更が発生する可能性のあるコンポーネントやクラスの構造，連携に柔軟性を与える方法と，(2)業務要件と実装技術を分離する方法，が存在する。
(1)はアーキテクチャやデザイン・パターン，開発言語，フレームワークなどで従来から試みられた方法である。(2)は最近多くの企業経営者が問題とするIT投資の戦略化にかかわる。最終的に使う技術は(1)に行き着くが，システムに対する取り組み方法が違う。ある意味で古くて新しい方法といえる。
疎結合に関する経験や知識は多岐にわたり，オブジェクト指向の課題というよりむしろソフトウェア設計全体の課題である。ただし，柔軟性に対するオーバーヘッドと実装の複雑化は，トレードオフの関係にある。すべてに有効な万能技術は存在しない。また，変化を100％予見するのは不可能なので，柔軟に技術やアプローチを変えて対応していく必要がある。
柔軟なシステム作りのためには，世の中をすべてオブジェクトで分類する世界観よりも，変化と変化しないモデルで分類する世界観の方がより根源的だと私は考える。東洋思想にも通じるところがある。これは，必ずしもオブジェクト指向の考え方と相反するわけではない。ただモデリングはある段階から世界観をどう構築するかという思想的な要素を含んでいる。逆に言えばアーキテクトたるもの，その段階にある程度足を踏み込まなければならない。例えば，James Coplien氏のマルチパラダイム・デザインでは，ドメインの共通性を抽出し可変性をパラメータ化することで再利用性を向上する。この手法には，変化をとらえる一種の思想的な考えが背景にある。
