SSブログ
ライブラリ、フレームワーク、アーキテクチャ設計 ブログトップ

オープン・クローズドの原則(OCP:The Open-Closed Principle) [ライブラリ、フレームワーク、アーキテクチャ設計]

Bertrand Meyerによるオープン・クローズドの原則(OCP:The Open-Closed Principle)は、クラスや関数を設計するだけでなく、アーキテクチャ(システム設計)においても重要な役割を果たします。1997年に出版されたBertrand Meyerの著書Object-Oriented Software Constructionで紹介されています。
ソフトウェアの構成要素(クラス、モジュール、関数など)は拡張に対して開いて(オープン:Open)いて、修正に対して閉じて(クローズド:Closed)いなければならない。
オープン・クローズドの原則(OCP:The Open-Closed Principle
大規模なシステムにおいて、ある機能を追加しようとする場合に、既存のモジュール群を多数修正しなければならないのであれば、この原則に反していることになります。もし、追加される機能が小さなものであっても、既存のシステムを多数修正しなければならないとなると、システム設計が誤っているのかもしれません。

私自身の経験から言えば、1996年に発売されたFuji Xerox DocuStation IM200では、当時のデジタル複合機(MFP)の基本サービスに加えてペーパーユーザインタフェースと呼ばれるサービスが搭載されていました。この開発においては、様々な工夫を私自身が考え出して組み込みました。特に、サービスを任意に追加できるようにする必要性を強く認識して、以下の2点を実現するように設計しました。
  • 個々のサービスを実装しているモジュールはすべてダイナミックロードされる。
  • システムは、個々のサービスがどのような機能を提供するのか一切知らない。
レイヤ構成の最上位層に位置するサービス層は、すべてがダイナミックロードされて機能を実現していました。これも一種のオープン・クローズドの原則に基づく設計だと思っています。サービスを追加するという機能拡張を行うのに、下位層のシステムを修正する必要がないということです。

こう説明すると当たり前のことにように思えるかもしれませんが、下手に設計すると、すべてのモジュールを静的にリンクして、たとえば、ユーザが指示をしたコピー操作をどのサービスモジュールが行うのかをシステム側がハードコードするような設計をしないとも限りません。私自身はそのようなシステムを多く見てきました。

IM 200の開発では、製品ではないサービスモジュールを色々と作成して、私も含めて開発者が遊んでいました。私自身は、デジタル時計サービス(操作パネル上にデジタル時計を大きく表示)やメッセージ表示サービス(自分のPC上で動作するMessagingToolから送ったメッセージが操作パネル上に表示される)など作成したりしました。

Fuji Xerox DocuStation IM 200を含むブログ

ビルドやテストも考慮したアーキテクチャ設計 [ライブラリ、フレームワーク、アーキテクチャ設計]

大規模なソフトウェア開発では、ビルドやテストも考慮したアーキテクチャ設計(あるいはシステム設計)が必要です。どのモジュールから順番にビルドして、テストできるかは、プロジェクト全体の開発効率に非常に大きな影響を与えます。

レイヤ構成のアーキテクチャであれば、当然、下位レイヤからビルド/テストを行い、それが上手く行けばその上のレイヤをビルド/テストするという順番で行うことが可能となります。

一方で、上手く出来上がった時には、確かに全体として機能するはずであるけれど、ビルドやテストが非常に面倒なシステム設計も可能です。このような設計では、ビッグバンインテグレーションが行われることがあったりします。そして、ちょっとした仕様変更でも多くの工数を必要としたりします。

アーキテクチャの検討において、ビルドやテストも考慮した議論が行われずに、単純に「機能が実現できるかできないか」という視点に陥る場合があります。ソフトウェアはどのような作り方をしても、工数さえ問わなければ、機能を何とか実現できます。しかし、実際の開発では、様々な要因が開発工数と品質に影響を与えます。下手すると、機能追加が非常に面倒なシステムが出来上がるかもしれません。

ソフトウェア開発では、ビルドやテストが困難なアーキテクチャ設計(システム設計)は、何かが間違っているのではないかとか、同じ機能を提供するもっと良い設計はないのかと考えてみる必要があります。
ライブラリ、フレームワーク、アーキテクチャ設計 ブログトップ