C++  OOP  ブジェクト指向

この記事は、2008年4月から発売の「インド式プログラミングバイブル C++言語とオブジェクト手法入門」より掲載しました。書籍の情報は、こちらをご覧ください。

1 オブジェクト指向プログラミング (OOP) の原則

1.1 OOP の概要
1.1.1 手続き型プログラミングと OOP の比較
1.1.2 OOP 言語
1.1.3 OOP の利点

1.1 OOP の概要

OOP とは何か、OOP が必要となる理由、C、Pascal、Basic などの従来の言語との違い、および OOP の原則を理解することは重要です。この章では、これらの点について説明し、本書で解説する機能の概要を示します。

ソフトウェアを設計する際に従うべきガイドラインは、"アルゴリズムの表現は、それがサポートするアプリケーションの分野をモデル化していなければならない" ということです。言い換えれば、問題に対するソリューションは、解決する問題と共通点があるということです。つまり、事前に問題を知らなくても、ソリューションの目的を認識できる必要があります。たとえば、適切に設計された在庫管理システムを見れば、その目的が在庫の数量および場所の記録を保持することであるとわかります。このことがわかるのは、ソリューションが、解決する問題と共通点があり、それを思い起こさせるからです。同様に、プログラミング言語の目的は、データ処理の問題に対するソリューションをアルゴリズムを使用して表現することです。その表現で使用される手法によって、ソリューションで問題の分野をどの程度適切にモデル化できるかが決まります。以前は、アルゴリズムの表現には手続き型プログラミングが使用されていました。最近では、これに代わって、オブジェクト指向プログラミングが使用されています。

初期のコンピュータはバイナリでプログラミングされていました。機械的なスイッチを使用してプログラムをロードしていました。大容量の記憶デバイスおよび大容量で安価なコンピュータ メモリの出現に伴って、最初の高水準コンピュータ プログラミング言語が登場しました。これによって、プログラマは、ビットやバイトで考える代わりに、一連の英語に似た命令を記述し、コンパイラを使ってコンピュータ用のバイナリ言語に変換できるようになりました。これらの言語は設計がシンプルで使いやすいものでした。これは、当時のプログラマは主に計算などの比較的単純なタスクを扱っていたからです。結果として、プログラムは非常に短く、およそ数百行のソース コードに限定されていました。

コンピュータの処理能力が向上するにつれて、より複雑なコンピュータ プログラムを開発できるようになりました。ただし、初期のプログラミング言語は、複雑なプログラミング タスクを実行するには力不足でした。これらの言語には、次のような制限がありました。

1. 既存のプログラムのコードを再利用することができませんでした。同じコードが必要なときには、単純に複製していました。
2. 危険な goto ステートメントによって制御が転送されていました。このため、プログラム内で頻繁にジャンプが発生し、制御のフローがどのように、どこに、なぜ行われるのかが示されないこともしばしばありました。
3. プログラム内の変数はすべてグローバルでした。長く入り組んだプログラム内でグローバル データのもっともらしい変化を突き止めることは、非常に面倒な作業でした。

長大なプログラムを記述、理解、および保守することは、プログラマにとって頭の痛い問題になっていました。プログラマたちは、より洗練されたアプリケーションを作成できるような新しい機能を備えた新しい言語を開発する必要性を感じていました。これを打開したのが、60 年代末から 70 年代初頭にかけて登場した手続き型プログラミングです。C、COBOL、FORTRAN などの言語を使用するプログラミングを手続き型プログラミングと呼びます。プログラマが理解に苦しんでいた長大なプログラムを、数百個のステートメントで構成される小さな単位に分割できるようになりました。これらの言語では関数/サブルーチン/プロシージャが導入され、人間である作成者にとってプログラムがよりわかりやすいものになりました。プログラムは関数に分割することができ、各関数は明確に定義された目的と、プログラム内の他の関数に対する明確に定義されたインターフェイスを持っています。手続き型プログラミングの原則を使用して構築されたプログラムの標準的な構成を、図 1.1 に示します。

手続き型プログラムは、プログラムの主要な目的を、プログラム内の関数になる小さな単位に分割することによって構築されます。各関数はそれぞれ独自のデータとロジックを持つことができます。関数間では、パラメータを使用して情報が受け渡されます。また、関数は関数のスコープの外部からアクセスできないローカル データを持つことができます。プログラム全体で、すべての関数で共有できるグローバル データを持つこともできます。図 1.2 に、手続き型プログラミングでのデータと関数の関係を示します。

手続き型プログラムでは、関数内でプロセスを分離することによって、あるプロシージャの別のプロシージャに対する影響を最小限に抑えています。また、これによって問題の切り分けも容易になっています。手続き型プログラミングでは、簡潔なコードを記述し、各関数に対する管理を維持することができます。グローバル変数の必要性は小さくなり、スコープが小さく、より管理が容易なローカル変数に置き換えられています。これらによって、コードを迅速かつ効率的に開発および保守できるようになりました。

手続き型プログラミングでは、"抽象化" という新しい概念が登場しました。抽象化によって、プログラマはエンティティを、内部の詳細を気にすることなく使用できます。手続き型プログラムでは、関数によってどのタスクが実行されるかがわかっていれば十分です。プログラマは、関数が信頼できる方法でタスクを実行する限り、タスクがどのように実行されるかを考慮する必要はありません。これは関数の抽象化と呼ばれ、手続き型プログラミングの重要な要素です。

手続き型プログラミングの主な特長は次のとおりです。

1. プログラムの主な目的が関数と呼ばれる小さな単位に分割されます。
2. グローバル データをプログラム内の関数で共有できます。
3. アクセスまたは操作するデータを、ある関数から別の関数に渡すことができます。

手続き型プログラミングは、およそ 20 年間、一般的に使用されてきました。ハードウェアの着実な向上と、ユーザーからの豊富な機能を持つプログラムに対する需要の高まりによって、プログラムの複雑さは何倍にもなり、手続き型プログラミングのアプローチにも徐々に限界が見えてきました。これは手続き型パラダイム (構成の原則) 自体の弱さによるものです。手続き型言語の失敗の主な理由の 1 つに、データの果たす役割が挙げられます。

手続き型言語では、すべての重点が何かをすることに置かれています。プログラムを関数に分割する際にも、このことに重点が置かれます。関数は、1 つのプログラム ステートメントと同様に何かの処理を実行します。実行する内容が複雑になる場合もありますが、やはり重点は実行することにあります。データはプログラムの存在理由であるにもかかわらず、手続き型パラダイムでは二流の地位が与えられています。たとえば、給与処理アプリケーションでは、重要な部分は、データを表示する関数でも、適切な入力をチェックする関数でもありません。重要な部分は給与データ自体です。

C や Pascal などの手続き型プログラミング言語は、データ構造 (配列、構造体、共用体、列挙体など) を定義し、プログラム内の任意の場所からデータを検査または変更する関数を提供します。プログラムが合理的なサイズを超えて増大すると、データ構造がプログラム全体で利用できるため、ある部分でデータ構造を変更するとプログラムの他の部分にも影響する可能性があるので、プログラムを管理できなくなります。

手続き型プログラミングのもう 1 つの問題は、主要なコンポーネントである関数とデータが、実世界を適切にモデル化していないという点です。たとえば、メニューやウィンドウなどの GUI の要素を作成するためにプログラムを作成している場合、メニューやウィンドウに対応する明確なプログラム要素がありません。これは、手続き型プログラミング パラダイムでは、言語の手続き型アプローチに問題を当てはめることに重点を置いているからです。

したがって、手続き型プログラミングの欠点は次のとおりです。

1. 実世界のモデルの表現が貧弱です。
2. ある関数でのグローバル データの操作が別の関数に影響する場合があります。
3. 処理の対象となるデータよりも、処理の実行 (手続き) に重点が置かれています。

手続き型プログラミングに見られた制限を打ち破るために、オブジェクト指向プログラミングが導入されました。