カプセル化
カプセル化（カプセルか、英: encapsulation）は、コンピュータプログラミングで用いられる概念で互いに関連するデータとロジックなどを1つのモジュールとしてまとめることである[1]。また、より広い意味ではまとめたモジュールの内側の詳細を外側から隠蔽することをも含む[2]。この隠蔽は計算機科学者デビッド・パーナスが提唱した情報隠蔽と同義である。
カプセル化はオブジェクト指向での使用が最も有名であり、そこではフィールドとそれを操作するメソッドをまとめたオブジェクトの内部要素への直接アクセスを制限するためのアクセスコンロールを設けている。内部隠蔽されたフィールドを操作または閲覧するためのメソッドは、ミューテイタ/アクセッサと呼ばれ、これはセッター/ゲッターの俗称でも知られている。フィールドとメソッドの一体化には、フィールド展開用のメモリ基底アドレスをアドホック多相表現にしたThis参照の機構が用いられている。これらカプセル化のコンセプトの定義と実装の書式は、オブジェクトの設計図に例えられているクラスに投影されている。オブジェクト指向のカプセル化は、特にデータ抽象の側面が強調されている。
なお、カプセル化はオブジェクト指向の専売特許ではなく、抽象データ型、プログラムモジュール、ソフトウェアコンポーネントの実装にも使用されている。
概要 編集
構造化プログラミングを提唱したエドガー・ダイクストラは、プログラムの段階的詳細化法の知見から、プログラムを構成するアルゴリズムとそのアルゴリズムで用いられるデータ構造は密接に関連しており、アルゴリズムをある程度詳細化してからでないと多くの場合そのデータ構造は決定できないことを指摘した[3]。
さらに、アルゴリズムに関連するデータ構造を決定するためには、まず必要なデータ構造の存在を変数名で代用、すなわち抽象（abstract）し（これをデータ抽象（data abstract）と呼ぶ）、アルゴリズムの方の詳細化を進めることでそのデータ抽象された変数名が必要とされる情報を徐々に集めてゆき、十分な情報が集まった段階でそのデータ構造を決定させればよいということを示した[注釈 1]。なお、データ抽象を駆使してアルゴリズムとそのデータ構造を洗練化（段階的詳細化）したものは真珠（pearl）[注釈 2]と呼ばれる[4][注釈 3]。
このように開発されたプログラムにおいては、アルゴリズムとそのデータ構造は一体不可分のようになるため、プログラムの拡張などにより、アルゴリズムを後から変更する必要が出てくると、必然的に一度決定したはずのデータ構造や関連操作を修正しなくてはならなくなる。しかも、その修正箇所は大規模なプログラム開発であれば多数の関連ソースコードの各所に散在してしまうことになる[注釈 4]。
以上のことを踏まえれば、ほとんど一体不可分のものであるアルゴリズムの操作と、そのアルゴリズムに関連するデータ構造に対しては、異なる名前を持つ異なる真珠として扱うよりも一つの変数名からなる一つのモジュール（module）とした方が、仮に後でアルゴリズムの変更を行うにしても変更箇所がそのモジュールの内部に限定されることになるので、保守管理しやすい。このように、関連するデータとその操作を一つの何かまとまりにまとめることを情報のカプセル化（encapsulation）またはモジュール化（modulization）と呼ぶ[注釈 5]。
情報隠蔽 編集
デイビッド・パーナスはモジュール間の結合に関する議論を進める上で、プログラムやモジュールに関する設計情報は濫りに公開してはならず、むしろ積極的に隠蔽すべきであるという情報隠蔽（information hiding）の考え方を説いた。つまり、公開すべきものはプログラムやモジュールの仕様であって、その実現手段ではないと主張した[5][注釈 6]。
公開すべき仕様上の機能を呼び出す機構はインターフェース（interface）と呼ばれる。インターフェースを経由することでモジュールの機能の情報隠蔽をすることができる。ほかに情報隠蔽を実現する機構としては、モジュールの機構自体に公開/非公開（public/private）の区別を指定する方法が一般的である。
脚注 編集
注釈 編集
- ^ 構造化プログラミング pp.58-65 における image型 はデータ抽象の例である。
- ^ なお、紛らわしい名称を持つプログラミング言語のPerl開発者であるラリー・ウォールは、構造化プログラミングの真珠（pearl）との関連性を明確には述べていない。本家インタビュー：Perl開発者ラリー・ウォール
- ^ ダイクストラやヴィルトの普及もあってか、以後「アルゴリズム」と「データ構造」と言う単語の入ったプログラミングに関する書籍が数多く出版されることとなった。
- ^ このような構成からなるプログラムは変更に弱く、バグが発生しやすいため保守管理が困難である。
- ^ 用法としてカプセル化という用語は情報隠蔽も含むことが多い。一方、モジュール化という用語はそういったニュアンスは少ない。
- ^ ソフトウェア業界においては、理想的には顧客が提示する仕様書に基づいてソフトウェアを開発し、そのソフトウェアが仕様書を満たしていれば顧客に納品することができる。つまり、顧客が提示する仕様書にある機能が実現されており、かつその機能を実行する限りにおいて動作検証されていれば、そもそも顧客が関知する理由の無い実装上必要となる機能の幾つかが不具合を有していても、そのソフトウェアは仕様書を満たしていると主張可能ということである。
出典 編集
- ^ 上田勲『プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則』秀和システム、2016年3月29日、84頁。ISBN 978-4-7980-4614-3。
- ^ 上田勲『プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則』秀和システム、2016年3月29日、86頁。ISBN 978-4-7980-4614-3。
- ^ 構造化プログラミング pp.58-65
- ^ 構造化プログラミング pp.68-69
- ^ 山崎(1990) p.131
参考文献 編集
- E.W.ダイクストラ、C.A.R.ホーア、O.-J.ダール 著、野下浩平,川谷慧,武市正人(共訳) 訳『構造化プログラミング』サイエンス社、1975年。
- 山崎利治『プログラムの設計』共立出版〈計算機科学/ソフトウェア技術講座〉、1990年。
- 落水 浩一郎『ソフトウェア工学実践の基礎』日科技連、1993年。
- D.L.Parnas (1971), “Information distribution aspects of design methodology”, Proceedings of IFIP Congress
