「オブジェクト指向プログラミング」の版間の差分

削除された内容 追加された内容
G000001 (会話 | 投稿記録)
→‎歴史: en:Object-oriented programming oldid=1051149906 の 歴史節のSIMULA 67の記述部を翻訳
RnTknn (会話 | 投稿記録)
デザインパターン一覧
タグ: ビジュアルエディター: 中途切替 曖昧さ回避ページへのリンク
177行目:
* [[プロトタイプベース]] - オブジェクトのクローンでオブジェクトを構築する。クラスとインスタンスの[[相対性]]をオブジェクトから撤廃して、プロトタイプでオブジェクトを体系化している。動的型付け中心。[[動的束縛|動的バインディング]]による多態性。
 
<!-- 動的型付けのオブジェクト指向言語もかなり使われているので疑問。 -->なお、場合によっては C言語などオブジェクト指向を支援しない言語でオブジェクト指向OOP的なプログラミングが行われることもある<!-- それについての書籍があったはず -->。<!-- OOPの三大要素は「なぜオブジェクト指向で作るのか」など数多くの著作に掲載されており、少なくとも日本では広く知られてると思うので取り合えず外しました。 -->
 
参考: <!-- [[クラスベース]]OOPの中心である[[クラス (コンピュータ)|クラス]]の実装様式を規定している以下の三項目は、 「クラスの実装様式」では意味がはっきりしない。-->後述のカプセル化、継承、ポリモーフィズムの3項目は、<!-- 日本では -->オブジェクト指向の三大要素などと言われることもあるが、広く認められたものではないし、OOPの特徴なのかOOP言語に求められる機能なのかという点も曖昧である。
<!-- 各要素の軽視重視と導入方法は言語別に様々である。 -->
 
=== クラスとインスタンス ===
227 ⟶ 224行目:
[[インタフェース (抽象型)|インターフェース]]は、[[カプセル化]]と[[継承 (プログラミング)|継承]]の[[派生型|サブタイピング]]用法を促進した機能である。情報隠蔽とデータ抽象とメソッド抽象を合わせて表現する。[[クラス (コンピュータ)|クラス]]から見たインターフェースは自身のサービスのモデル化である。OOPの[[インタフェース (抽象型)|インターフェース]]は基本的には抽象メソッドのみで構成される[[抽象型]]と定義されている。その実装方式は純粋抽象クラスが基本形にされており、インスタンス化はできない継承専用クラスになって多重継承が前提にされている。インターフェースの抽象メソッドは、その実装クラスの同名具象メソッドで[[オーバーライド]]される。インターフェースの各抽象メソッドはセッター・ゲッター・プロセスとして動作し、その実装内容は隠蔽されて実行時ごとに決定される。その代表使用例は[[ソフトウェアコンポーネント]]間の相互通信媒体である。
 
OOP原点の[[Smalltalk]]処理系由来の[[トレイト]]は、[[クラス (コンピュータ)|クラス]]への機能注入を目的にした[[メソッド (計算機科学)|メソッド]]の集合体であり、トレイトの多重継承を扱う作法は[[ミックスイン]]と呼ばれている。トレイトの継承はインクルードともされ、これはUML[[クラス図]]の特化実装ではない第三の継承概念になるので、従来の標準OOP路線からは外れていた。後の[[依存性逆転の原則]]および[[依存性の注入]]の[[デザインパターン (ソフトウェア)|デザインパターン]]では、[[Mixin|Mix-in]]の作法が注目されるようになり、そこでの[[トレイト]]の役割を与えた[[インタフェース (抽象型)|インターフェース]]の応用設計が普及し扱われている。そのMix-inをUML[[クラス図]]は、特定の機能([[サーバー]]や[[データベース]]など)から”実現”されたインターフェース(依存対象)に向けてオブジェクトが”関連”するという図式にしている。この手法は分散オブジェクト技術の後継としてのDIコンテナで用いられている。
 
<!-- 以下、[[en:Object-oriented programming]] oldid=1047374345 の翻訳 -->== デザインパターン一覧 ==
 
=== 継承と振る舞いサブタイピング ===
[[継承 (プログラミング)|継承]]が[[Is-a]]関係を表現して、[[サブクラス (計算機科学)|サブクラス]]の[[インスタンス]]は[[スーパークラス (計算機科学)|スーパークラス]]の[[インスタンス]]を安全に置換できるという直感は、多くのOOP言語には当てはまっておらず、ミュータブルな[[オブジェクト (プログラミング)|オブジェクト]]を扱っていても同様である。型チェック機構付きのサブタイプ多相は、{{仮リンク|振る舞いサブタイピング|en|Behavioral subtyping}}の正当性までを保証しない。一般的に振る舞いサブタイピングは[[非決定性チューリングマシン|非決定性]]なので、そのための言語機能の実装は非現実的であり、[[クラス (コンピュータ)|クラス]]またはオブジェクトの継承関係の設計は、プログラマの手によって注意深く行われる必要がある。スーパークラスとサブクラス間の理想的な振る舞いサブタイピングを実現するためのデザインパターンとしてよく知られているのが、[[リスコフの置換原則]]である。
 
=== GOFデザインパターン ===
1994年に”[[Gang of Four]]”がその著作で発表した23のデザインパターンは、余りに有名である。
: 生成のパターン<gallery heights="30" perrow="6">
ファイル:Abstract Factory UML class diagram.svg|[[Abstract Factory パターン|Abstract factory]]
ファイル:Builder UML class diagram.svg|[[Builder パターン|Builder]]
ファイル:Factory Method UML class diagram.svg|[[Factory Method パターン|Factory Method]]
ファイル:Prototype UML.svg|[[Prototype パターン|Prototype]]
ファイル:Singleton UML class diagram.svg|[[Singleton パターン|Singleton]]
</gallery>
: 構造のパターン<gallery heights="30" perrow="8">
ファイル:Adapter pattern UML diagram.PNG|[[Adapter パターン|Adapter]]
ファイル:Bridge UML class diagram.svg|[[Bridge パターン|Bridge]]
ファイル:Composite UML class diagram (fixed).svg|[[Composite パターン|Composite]]
ファイル:Decorator UML class diagram.svg|[[Decorator パターン|Decorator]]
ファイル:Facade UML class diagram.svg|[[Facade パターン|Facade]]
ファイル:Flyweight UML class diagram.svg|[[Flyweight パターン|Flyweight]]
ファイル:UML DP Proxy.png|[[Proxy パターン|Proxy]]
</gallery>
: 振る舞いのパターン<gallery heights="30" perrow="12">
ファイル:Chain of responsibility UML diagram.png|[[Chain of Responsibility パターン|Chain of Responsibility]]
ファイル:Command Design Pattern Class Diagram.png|[[Command パターン|Command]]
ファイル:InterpreterUMLDiagramm.png|[[Interpreter パターン|Interpreter]]
ファイル:Iterator UML class diagram.svg|[[Iterator パターン|Iterator]]
ファイル:Mediator design pattern.png|[[Mediator パターン|Mediator]]
ファイル:Memento design pattern.png|[[Memento パターン|Memento]]
ファイル:Observer UML smal.png|[[Observer パターン|Observer]]
ファイル:State Design Pattern UML Class Diagram.svg|[[State パターン|State]]
ファイル:Strategy Pattern in UML.png|[[Strategy パターン|Strategy]]
ファイル:Template Method UML class diagram.svg|[[Template Method パターン|Template Method]]
ファイル:Visitor UML class diagram.svg|[[Visitor パターン|Visitor]]
</gallery>
 
=== 責任駆動設計とデータ駆動設計 ===
OOPで提唱された責任駆動設計(RDD)とは、特定の機能を実現する責任およびその機能が共有する情報に基づいて、[[クラス (コンピュータ)|クラス]]を定義していくデザインパターンである。責任駆動設計では、振る舞い抽象としてのクラスに焦点を当てており、必然的に[[インタフェース (抽象型)|インターフェース]]や[[抽象クラス]]が多用されることになる。
 
OOPにおけるデータ駆動設計とは、保持する[[データ構造]]に基づいて、クラスを定義していくデザインパターンである。データ駆動設計では、データ抽象としてのクラスに焦点を当てており、[[カプセル化]]と[[抽象データ型]]の概念に重きが置かれる。{{仮リンク|レベッカ・ウーフ‐ブロック|en|Rebecca Wirfs-Brock}}によって彼女の責任駆動設計と、従来のデータ駆動設計は対比されるようになっている。
 
===SOLID、GRASPのガイドライン===
242 ⟶ 279行目:
[[GRASP]](General Responsibility Assignment Software Patterns)は、[[:en:Craig Larman|クレーグ・ラーマン]]が提唱したもう一つガイドラインである。
<!-- 以上、[[en:Object-oriented programming]] oldid=1047374345 の翻訳 -->
== 公式意味論 ==
数々の識者によってOOPで扱われる概念を公式化する試みが行われている。OOP概念の解釈に用いられる代表的なコンセプトは以下の通りである。
 
* [[F余代数|''F''余代数]](''F''-coalgebra)
* [[抽象データ型]](abstract data type) - {{仮リンク|存在型|en|Type_system#Existential_types}}を含む。なお、動的ディスパッチはサポートしていない。
* [[再帰データ型]](recursive type)
* [[カプセル化|カプセル化状態]](encapsulated state)
* [[継承 (プログラミング)|継承]](inheritance)
* [[レコード (計算機科学)|レコード]](record)- 関数リテラルを持つレコードがオブジェクトと見なされるが、本格的なOOPになるにはそれ以上の複雑さが必要である。
 
”オブジェクト”の共通認識的な定義または理論を見つけようとする試みはそれほど成功していない。{{仮リンク|ルカ・カーデリ|en|Luca Cardelli}}らによる[http://portal.acm.org/citation.cfm?id=547964&dl=ACM&coll=portal ''A Theory of Objects'']<ref name="AbadiCardelli">{{Cite book|和書|first=Martin|last=Abadi|title=A Theory of Objects|url=http://portal.acm.org/citation.cfm?id=547964&dl=ACM&coll=portal|year=1996|isbn=978-0-387-94775-4|publisher=Springer-Verlag New York, Inc.|author-link=Martin Abadi|author2=Cardelli, Luca}}</ref>は、比較的成功している例とされる。
 
== オブジェクト指向言語一覧 ==