オブジェクト指向で実現できる保守性・拡張性:保守性・拡張性に優れたシステムを作る(2)(3/3 ページ)
オブジェクト指向開発を行えば、保守性・拡張性が良くなるといわれますが、本当にそうなのでしょうか? 第1回「保守性と拡張性の定義」では、現状のシステム開発の問題点を指摘し、そのうえで、そもそも保守性・拡張性とはどのようなものなのかを説明しました。今回は、拡張性・保守性を高めるための重要な考え方について解説をしていきます。
保守性・拡張性の高いシステムの考え方
保守性・拡張性の高いシステムとはどのようなものでしょうか。それには共通的に利用される部分と共通的に利用されない部分をうまく分離できるとよさそうです。そのためには、共通的に利用される部分はビジネスロジックなどが重複しないようにすることや、共通的に利用されない部分からの影響を排除することで、保守性・拡張性を高めます。それではどのように分析設計すればよいのでしょうか?
(1)普遍的な構造と固有な構造
普遍的[*4]な構造とは、共通的に使われるクラスの構造で、固有な構造とは、ほかから使われることはなく、一連の手続きを実行するクラスの構造と考えることができます。
普遍的なクラス構造は、データを中心とし、そのデータを利用するビジネスロジックを持ったクラスが該当します(データは、いろいろなところで利用されます)。普遍的なクラス構造は、概念を基にした構造になります。普遍的な構造にあるクラスの多くは、属性を持っており、データを永続化する必要があります。永続化には、RDBやOODBなどが利用されます。
固有なクラス構造は、「注文する」などのユーザーに提供するサービスが該当します。サービスの中には、「会員を確認する」「製品を注文する」などの手続きがあり、手続きから「年齢を取得する」「在庫を確認する」などのビジネスロジックを利用して、処理を実行していきます。
固有な構造のサービスは、普遍的な構造のデータやビジネスロジックを利用して一連の手続きを実行することになります。それでは、普遍的な構造や固有な構造にシステムをうまく分離して設計するには、どのように考えていけばよいでしょうか。
普遍的な構造にするには
概念から導き出されるクラスを中心に、サービスなどから共通的に利用されるクラス群の構造を定義します。普遍的な構造のクラスの属性や操作を、結合度が高くなるようにまとめて、カプセル化を行い自律した構造にすることにより、サービスが追加・変更されても影響がないようにします。
また、汎化構造や共通的な機能を分析することにより、機能を整理します。これにより普遍的な構造から重複したロジックをなくし、データの種類により振り分ける条件式[*5]をなくすことができます。
これにはポリモーフィズムや継承が利用できます。新しい商品などが増えた場合には、ポリモーフィズムを実装したクラスを作成し追加するだけでよくなります。ビジネスロジックの変更や追加は変更個所が極少化されるか、またはホットスポットを利用して簡単に変更することができます。そして、普遍的な構造のクラス群はサブシステムなどを導入することにより、コンポーネント化を検討します(ホットスポットやサブシステムについては連載の中で説明します。ここではサブシステムはパッケージを利用したコンポーネントと考えてください)。
固有な構造にするには
固有な構造のクラス群は手続きの流れをコントロールするクラスで構成され、ビジネスロジックを持つ普遍的な構造のクラスやサブシステムを利用するようにします。固有な構造は主にサービスなどに適用します。
このとき、普遍的な構造と固有な構造の間にポリモーフィズムを導入します。固有な構造からはポリモーフィズムを通して普遍的な構造のクラスやサブシステムにアクセスします。これにより、普遍的な構造と固有な構造のクラスやサブシステムの依存関係を少なくし、コンポーネント化を促進します。
(2)フレームワークを作る
普遍的な構造と固有な構造を構築することはフレームワークを作ることになります。Strutsを考えてみてください。普遍的な構造と固有な構造をうまく分離して構築しておき、変更がある部分はポリモーフィズムや継承を利用することにより、必要な部分だけを定義すれば済むようになっています。Strutsを利用する際に既存のロジックにロジックや条件式を追加することはありません。
業務システムでも業務のフレームワークを作ることにより、保守性・拡張性を高めることができます。フレームワークを作るには、固有な構造と普遍的な構造のシステムを構築することが必要です。そのためには、上流工程では概念やサービスを基に概念の汎化構造などを検討することにより、普遍的な構造と固有な構造を分析し、その結果を基に下流工程ではポリモーフィズムや継承などを利用して機能を整理整頓し、普遍的な構造や固有な構造を作り上げます。
このように、上流工程では業務に関する構造を分析し、その結果を基に下流工程では分散性や永続化などの技術的要件や性能などの制約を検討し、実現可能なシステム構造を設計していきます。ただ、分析から設計へ変換するのは難しいことです。汎化構造なども単純にポリモーフィズムや継承に変換できるわけではありません。いろいろな制約が発生し、オブジェクト指向らしさがなくなってしまうこともあります。これについては連載のなかでわかりやすく説明できればと考えています。
今回はオブジェクト指向開発における保守性・拡張性の基本的な考え方になる「概念の汎化構造」と「ポリモーフィズム」についてと、「普遍的な構造と固有な構造」についてお話ししました。ページに限りがあるのでテーマを絞りかなりはしょって説明しました。オブジェクト指向にはほかにも多くの考え方があるので、興味を持たれたようでしたら参考文献を参照してください。
次回は「概念モデリングとユースケース分析」についてお話ししたいと思います。
Copyright © ITmedia, Inc. All Rights Reserved.