カプセル化

索引トップ用語の索引ランキングカテゴリー

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2024/05/29 23:39 UTC 版)

概要

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

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

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

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

脚注

注釈

^ 構造化プログラミング 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