カプセル化

出典: フリー百科事典『ウィキペディア(Wikipedia)』

出典: フリー百科事典『ウィキペディア(Wikipedia)』

プログラミングにおけるカプセル化(カプセルか、: encapsulation)とは、関連するデータやその操作を一つのなにか分割の単位(カプセル)にまとめることを言う。カプセル化の概念は、D.L.パルナスの情報隠蔽(information hiding)の構成概念の一つとして見ることができる[1]

オブジェクト指向プログラミングにおけるオブジェクトは、クラスによる情報のカプセル化を行うことで作られる。

概要[編集]

構造化プログラミングを提唱したエドガー・ダイクストラは、プログラムの段階的詳細化法の知見から、プログラムを構成するアルゴリズムとそのアルゴリズムで用いられるデータ構造は密接に関連しており、アルゴリズムをある程度詳細化してからでないと多くの場合そのデータ構造は決定できないことを指摘した[2]

さらに、アルゴリズムに関連するデータ構造を決定するためには、まず必要なデータ構造の存在を変数名で代用、すなわち抽象(abstract)し(これをデータ抽象(data abstract)と呼ぶ)、アルゴリズムの方の詳細化を進めることでそのデータ抽象された変数名が必要とされる情報を徐々に集めてゆき、十分な情報が集まった段階でそのデータ構造を決定させればよいということを示した[3]。なお、データ抽象を駆使してアルゴリズムとそのデータ構造を洗練化(段階的詳細化)したものは真珠(pearl)[4]と呼ばれる[5][6]

このように開発されたプログラムおいては、アルゴリズムとそのデータ構造は一体不可分のようになるため、プログラムの拡張などにより、アルゴリズムを後から変更する必要が出てくると、必然的に一度決定したはずのデータ構造や関連操作を修正しなくてはならなくなる。しかも、その修正箇所は、大規模なプログラム開発であれば多数の関連ソースコードの各所に散在してしまうことになる[7]

以上のことを踏まえれば、ほとんど一体不可分のものであるアルゴリズムの操作とそのアルゴリズムに関連するデータ構造に対しては、異なる名前を持つ異なる真珠として扱うよりも一つの変数名からなる一つのモジュール(module)とした方が、仮に後でアルゴリズムの変更を行うにしても変更箇所がそのモジュールの内部に限定されることになるので、保守管理しやすい。このように、関連するデータとその操作を一つの何かまとまりにまとめることを情報のカプセル化(encapsulation)またはモジュール化(modulization)と呼ぶ[8]

情報隠蔽(information hiding)

パルナス(D.L.Parnas)はモジュール間の結合に関する議論を進める上で、プログラムやモジュールに関する設計情報は濫りに公開してはならず、むしろ積極的に隠蔽すべきであるという情報隠蔽(information hiding)の考え方を説いた。つまり、公開すべきものはプログラムやモジュールの仕様であって、その実現手段ではないと主張した[9][10]

公開すべき仕様上の機能を呼び出す機構はインターフェース(interface)と呼ばれる。インターフェースを経由することでモジュールの機能の情報隠蔽をすることができる。ほかに情報隠蔽を実現する機構としては、モジュールの機構自体に公開/非公開(public/private)の区別を指定する方法が一般的である。

脚注[編集]

  1. ^ その情報隠蔽の概念と同一視されることも多い。パルナス自身は分割の単位としてカプセルという用語ではなくモジュール(module)の用語を用いている。Parnas(1971)
  2. ^ 構造化プログラミング pp.58-65
  3. ^ 構造化プログラミング pp.58-65 における image型 はデータ抽象の例である。
  4. ^ なお、紛らわしい名称を持つプログラミング言語のPerl開発者であるラリー・ウォールは、構造化プログラミングの真珠(pearl)との関連性を明確には述べていない。本家インタビュー:Perl開発者ラリー・ウォール
  5. ^ 構造化プログラミング pp.68-69
  6. ^ ダイクストラやヴィルトの普及もあってか、以後「アルゴリズム」と「データ構造」と言う単語の入ったプログラミングに関する書籍が数多く出版されることとなった。
  7. ^ このような構成からなるプログラムは変更に弱く、バグが発生しやすいため保守管理が困難である。
  8. ^ 用法としてカプセル化という用語は情報隠蔽も含むことが多い。一方、モジュール化という用語はそういったニュアンスは少ない。
  9. ^ 山崎(1990) p.131
  10. ^ ソフトウェア業界においては、理想的には顧客が提示する仕様書に基づいてソフトウェアを開発し、そのソフトウェアが仕様書を満たしていれば顧客に納品することができる。つまり、顧客が提示する仕様書にある機能が実現されており、かつその機能を実行する限りにおいて動作検証されていれば、そもそも顧客が関知する理由の無い実装上必要となる機能の幾つかが不具合を有していても、そのソフトウェアは仕様書を満たしていると主張可能ということである。

参考文献[編集]

  • E.W.ダイクストラ、C.A.R.ホーア、O.-J.ダール 『構造化プログラミング』 野下浩平,川谷慧,武市正人(共訳)訳、サイエンス社、1975年
  • 山崎利治 『プログラムの設計』 共立出版〈計算機科学/ソフトウェア技術講座〉、1990年
  • 落水 浩一郎 『ソフトウェア工学実践の基礎』 日科技連、1993年
  • D.L.Parnas (1971), “Information distribution aspects of design methodology”, Proceedings of IFIP Congress 

関連項目[編集]