オブジェクト指向プログラミング
この項目﹁オブジェクト指向プログラミング﹂は途中まで翻訳されたものです。︵原文‥en:Object-oriented programming(13:57, 15 November 2021 UTC)の翻訳︶
翻訳作業に協力して下さる方を求めています。ノートページや履歴、翻訳のガイドラインも参照してください。要約欄への翻訳情報の記入をお忘れなく。︵2021年11月︶ |
歴史
編集![](http://upload.wikimedia.org/wikipedia/commons/1/18/Oop-uml-class-example.png)
Button
クラスは、データを表す変数xsize
など︶と関数︵図中 draw()
など︶を持つ。一般的なクラスは継承によりサブクラスを持つことができる。また、オブジェクトはクラスのインスタンスである。
私は、オブジェクトとは、生物の細胞やネットワーク上の個々のコンピュータのようもの、そしてそれらのコミュニケーションは専らメッセージによって行なわれるもの、と考えていました (つまり、メッセージングは最初から存在していたのですが、プログラミング言語でメッセージングを実用的かつ効率的に行う方法を見つけるまでには時間がかかりました)。
![](http://upload.wikimedia.org/wikipedia/commons/thumb/f/f8/Tiobeindex.png/350px-Tiobeindex.png)
OOPLの特徴
編集オブジェクト指向プログラミング言語 (OOPL) では、オブジェクトを使用するが、言語仕様でOOP対応を謳っていても、関連する技術や構造のすべてが言語機能により直接サポートされているわけではない。以下に挙げる特徴は、特に言及されている例外を除いて、クラス指向やオブジェクト指向の傾向が強いとされる言語 (あるいはOOPをサポートするマルチパラダイムプログラミング言語)に共通すると考えられるものである。
非OOPLとの共通点
編集クラスとオブジェクト
編集オブジェクト指向プログラミング(OOP)をサポートする言語は、コードの再利用と拡張性のために、典型的には、クラスまたはプロトタイプの形で継承を使用する。クラスを使用するものは、主に二つの概念をサポートする。
- クラス
- 与えられた型やクラスのオブジェクトのデータ形式やそれらを利用可能な手続きの定義であり、また、データや手続き (クラスメソッドとも呼ばれる)そのものを含む場合もある。つまり、クラスは、メンバーとなるデータや手続きを含むものである。
- オブジェクト
- クラスのインスタンス
オブジェクトは、システムが扱おうとする(多くは現実世界の)対象を表現したものである。例えば、描画アプリケーションにおける「円」・「四角」・「メニュー」などのオブジェクトや、オンラインショッピングシステムにおける「ショッピングカート」・「顧客」・「商品」などのオブジェクトがある[18]。 オブジェクトは、ファイルのオープンを表すオブジェクトや、米国慣用単位からメートル法に変換するサービスを提供するオブジェクトのように、より抽象的なエンティティを表すこともある。
オブジェクト指向プログラミングとは、単なるクラスやオブジェクトではなく、データフィールドやメソッドを含んだオブジェクト (データ構造)を中心としたプログラミングパラダイム全般のことです。クラスを使って、関係のないメソッドをまとめて整理する——これがオブジェクト指向の本質ではないことを理解しましょう。
name
フィールドに "Mary"
が設定されているオブジェクトは、クラスEmployee
のインスタンスとなる︶。OOPの手続きはメソッドと呼ばれ、変数は、フィールド、メンバー、属性、プロパティとも呼ばれる。関連して、以下のような用語がある
クラス変数
クラス自体に属する。変数をクラス全体に唯一のものとして所有する。
インスタンス変数または属性
各々のオブジェクトに属する。データはオブジェクトごとに所有する。
メンバ変数
特定のクラスで定義されるクラス変数とインスタンス変数の両方を指す。
クラスメソッド
クラス自体に属する。クラス変数へのアクセスのみ有し、手続き呼び出しからの入力のみ受け付ける。
インスタンスメソッド
各々のオブジェクトに対して、呼び出された特定のオブジェクトのインスタンス変数、入力、およびクラス変数にアクセスできる。
オブジェクトは、複雑な内部構造を持った変数のようにアクセスされるが、多くの言語で実質的にはポインタでありインスタンス ︵ヒープやスタック内のメモリ上オブジェクト︶への参照として機能する。オブジェクトは、内部コードと外部コードを分離を可能とする抽象化の層を提供する。外部のコードは、特定の入力引数の組み合わせで特定のインスタンスメソッドを呼び出したり、インスタンス変数を読み込んだり、インスタンス変数に書き込んだりすることで、オブジェクトを使用することができる。オブジェクトは、コンストラクタと呼ばれるクラス内の特定メソッドを呼び出すことで生成される。プログラムは実行中に、それぞれ独立して操作することが可能な同じクラスのインスタンスを多数作成することができる。これは、同じ手続きを異なるデータセットで簡便に利用する方法となる。
クラスを使用するOOPをクラスベース・プログラミングと呼ぶことがあるが、プロトタイプベース・プログラミングではクラスを使用しないのが一般的である。そのため、オブジェクトとインスタンスという概念の定義は、それぞれで大きく異なるが類似した用語が用いられている。
言語によっては、トレイトやmixinのような概念を用いてクラスやオブジェクトを構成することが可能である。
クラスベース対プロトタイプベース
編集動的ディスパッチとメッセージパッシング
編集カプセル化
編集pri
vate
というキーワードで指定し、クラス外のコードが使用することを意図したメソッドをpublic
というキーワードで指定することができる。また、メソッドはpublic、private、またはpr
otected
︵同クラスとそのサブクラスからのアクセスは許可するが、異なるクラスのオブジェクトからのアクセスは許可しない︶のように中間のアクセスレベルとすることもできる。また他の言語 ︵Pythonなど︶では、アクセス制限は、命名法などの慣例によってのみ強制される ︵例えば、private
のメソッドはアンダースコアで始まる名前を持つ、など︶。カプセル化することで、外部のコードがオブジェクトの内部動作に関与してしまうことを防ぐことができ、リファクタリングを容易にする。例えば、クラスの設計者は、外部のコードは変更することなく、そのクラスのオブジェクト内部のデータ表現を変更することができる ︵公開されているメソッドの呼び出しが同じように動作する限りにおいて︶。また、特定のデータに関連するすべてのコードを同じクラスに配置することで、他のプログラマが理解しやすいように整理することもできる。カプセル化は、疎結合を促進する技術である。
コンポジション、継承、委譲
編集Employee
クラスは Person
クラスを継承する場合、親クラスで利用できるデータやメソッドは、子クラスでも同じ名前で利用可能である。また、Person
クラスは、first_name
と last_
name
という変数を make_full_name()
というメソッドで定義した場合、これらの定義はEmployee
クラスでも利用可能である。加えて、Employee
クラスには変数 posi
tion
と salary
を追加することもできる。この手法では、同じ手続きやデータ定義を簡単に再利用できるだけでなく、現実世界の関係を直感的に反映できる可能性を広げる。開発者は、データベースのテーブルやプログラミングのサブルーチンを扱うのではなく、開発アプリケーションのユーザーがより精通しているドメインのオブジェクトを扱うことができる[19]。
サブクラスはスーパークラスで定義されたメソッドをオーバーライドできる。言語よっては多重継承が可能だが、多重継承ではオーバーライドの解決は複雑になる可能性がある。また、言語によってはmixinを特別にサポートしているものもあるが、多重継承をサポートする言語では、mixinは単に is-a-type-of の関係を表すことのないクラスの一つである。mixinは典型的には、同一のメソッドを複数のクラスに追加するために使われる。例えば、共通の親クラスを持たないFileReader
クラスとWebPageScraper
クラスに、unicode_to_ascii()
というメソッドを持つUnicodeConversionMixin
クラスを含ませる︵mixinする︶ことにより共通のメソッドを提供することができる。
抽象クラスは、オブジェクトへインスタンス化することはできない。インスタンス化できる他の具象クラスが継承するためにのみ存在する。Javaでは、final
キーワードを用いて、クラスがサブクラス化されるのを防止できる。
Composition over inheritanceの方針は、継承の代わりに合成を使って has-a 関係を実装することを提唱している。例えば、EmployeeクラスはPersonクラスを継承する代わりに、各Employeeオブジェクトの内部にPersonオブジェクトを含めることで、仮にPersonクラスが公開された属性やメソッドを多数持っていても、外部のコードからは隠せるようにする。また、Goのように、継承を全くサポートしていない言語も存在する。
開放/閉鎖原則は、クラスやメソッドは﹁拡張に対しては開放的であるが、変更に対しては閉鎖的であるべき﹂という原則を提唱している。
委譲もまた、継承の代わりに利用できる言語機能である。
ポリモーフィズム
編集オープンな再帰
編集オープンな再帰[20]をサポートする言語では、オブジェクトのメソッドは同じオブジェクト上の他のメソッドや自分自身を呼び出すことができる。通常はthis
やself
と呼ばれる特別な変数やキーワードを使用して呼び出しをするのが一般的であるが、この変数は「遅延結合」であり、あるクラスで定義されたメソッドが、そのサブクラスで後から定義された別のメソッドを呼び出すことができる。
デザインパターン
編集継承とBehavioral subtyping
編集GoFデザインパターン
編集オブジェクト指向とデータベース
編集OOPと制御構造
編集責任駆動設計 対 データ駆動設計
編集SOLID、GRASPのガイドライン
編集SOLIDのガイドラインは、プログラミングにおける五つの実践の頭文字をとった語呂合わせであり、マイケル・C・フェザーズ[28]が考案し提唱したものである
- S : 単一責任の原則(英語版)
- O : 開放/閉鎖原則
- L : リスコフの置換原則
- I : インターフェイス分離の原則(英語版)
- D : 依存性逆転の原則
GRASP(General Responsibility Assignment Software Patterns)は、クレーグ・ラーマンが提唱したもう一つガイドラインである。
形式意味論
編集脚注
編集注釈
編集- ^ 1995年6月 Visual FoxPro 3.0, FoxPro は手続き型言語からオブジェクト指向言語へと進化した。Visual FoxPro 3.0では、データベースコンテナ、シームレスなクライアント/サーバー機能、ActiveXのサポート、OLEオートメーションとヌルのサポートが導入された。Summary of Fox releases
出典
編集出典
編集関連項目
編集システム
編集- CADES
- Common Object Request Broker Architecture (CORBA)
- Distributed Component Object Model
- Distributed Data Management Architecture
- Jeroo