継承を積極的に利 することを推奨する専門家の主張 正しい設計を うには継承を正確に使 する事が極めて重要である [Ian Joyner] 開放閉鎖原理 (Open-Close Principle) を可能とするのは継承だけである [Bertrand Meyer] 表 1-1 共変化(co-varia

Transcription

1 第 1 回 : 継承 1 科学的に継承を理解する準備 今回から 継承 について解説します まずは 設計モデル を対象として継承の解説をします モデ ルには 設計モデル 概念モデル 分析モデル があります 設計モデル は 概念モデル 分析モデル とは異なり プログラミング 語や動作させる環境を考慮したモデルです ( 概念モデル 分析モデル は特定のプログラミング 語や動作環境を考慮しないで問題空間の構造と振る舞いおよび制約に焦点をおいたモデルを作成します ) 問題空間 現実の対象 概念モデル 図 1-1 概念モデル 分析モデル と 設計モデル ではモデル作成の目的や視点が異なるので 継承 に対して異なる理論 定理 原理を利 します 概念モデル 分析モデル で継承をどのように考えてモデルを うかについては 別の機会に解説したいと考えています 継承 の可能性を探る 今回は継承を科学的に理解するために準備の解説をします 継承 は 集約/ コンポジッション や 総称 ( ジェネリック / テンプレート ) と共に, オブジェクト指向でソフトウェアコンポーネンを組み てる際の基本的なメカニズムを提供します 効果的にオブジェクト指向設計をおこないたければ 継承 を効果的に利 することが重要です 継承はソフトウエア開発技法や 語設計の専門家の間でも議論が多い技術テーマですが 継承を正確に理解して設計と実装に利 できるようになると 劇的な効果を得る事が可能となります 具体的にはどのような効果があるのか代表的な専門家の意 を取り上げ ていきましょう 特に継承を積極的に利 することを提案している専門家の意 に を傾け 継承の意味と効果を 科学的 に理解していく準備とすることにします 科学的モデリング 1 回 継承 1 CO PYRIGHT HASHIM OT O SO FTW ARE CO NS U LT IN G INTEN AT IONA L INC. A LL R IGHTS RESE RVED.

2 継承を積極的に利 することを推奨する専門家の主張 正しい設計を うには継承を正確に使 する事が極めて重要である [Ian Joyner] 開放閉鎖原理 (Open-Close Principle) を可能とするのは継承だけである [Bertrand Meyer] 表 1-1 共変化(co-variant) 逆変化(contra-variant) 無変化(no-variant) の継承 Ian Joynerは 彼の書著である文献 [1-1] の中で C++JavaおよびEiffelを比較しながら継承の正しい理解と利 が劇的にソフトウエアの設計と実装の能 を向上させることを 説しています Ian Joynerは 実システムの開発において スーパークラスとサブクラスの間の継承関係では is-a 関係あるいは kind-of 関係が成 するが 共変化(co-variant) による継承の利 が多いことを紹介しています 共変化(co-variant) はスーパークラスが型 Aの引数を持っている場合, それをA 型のままに保つか,A の任意のサブクラスの型に再定義出来ることです 共変化(co-variant) の継承以外に 逆変化 (contra-variant) であり 継承が逆の方向に変化することを表します つまり サブクラスで再定義された操作 ( メソッド / 関数 ) の引数の型が スーパークラスの操作 ( メソッド / 関数 ) の型でなければなりません 無変化(no-variant) はJavaやC++ で採 されており 引数の型をサブクラスで再定義できません なお 共変化 (co-variant) 逆変化(contra-variant) 無変化(no-variant) は 操作( メソッド / 関数の ) 返り値と引数に対して 別々に説明する必要がありますが 今回は割愛します Ian Joynerは Erich Gamma 達の有名なデザインパターンを掲載した書籍 ( 文献 [1-6]) を例に挙げ 共変化(co-variant) による継承を いた多くのパターンが存在していることを述べています 具体的には Abstract Factoryパターン Factory Methodパターン Bridgeパターン lteratorパターン Mediatorパターン Observerパターン Template Methodパターンなどが該当します これらのパターンが 共変化 (co-variant) の継承であることを理解した上で利 しないと品質や再利 に影響を与えます 優れた開発が困難になるので要注意です なお JavaやC++ やC# をはじめとする広く利 されているオブジェクト指向 語は 直接 共変化 (co-variant) の継承のメカニズムを採 していませんが 共変化 (co-variant) の継承メカニズムを補足する技法がいくつかあります しかし 直接的に 共変化 (co-variant) の継承のメカニズムがないので Abstract Factoryパターン Factory Methodパターン Bridgeパターン lteratorパターン Mediatorパターン Observerパターン Template Methodパターンなどの 共変化 (co-variant) のパ Page 2

3 ターンを使う時は 共変化 (co-variant) の継承メカニズムを補足する技法を併 することが求められます 共変化(co-variant) 逆変化(contra-variant) 無変化(no-variant) の継承や 共変化 (covariant) の継承メカニズムを補足する技法の詳しい解説は やはり機会を改めて本コラムで詳しく解説します 開放閉鎖原理(Open-Close Principle) Bertrand Meyerは 極めて重要な設計原理 開放閉鎖原理 (Open-Close Principle) を最初に提唱した人として知られています Bertrand Meyerは有名なオブジェクト指向 語 Eiffelの設計者です Bertrand Meyerは文献 [1-2] 及び [1-3] の中で 継承の有 性を詳しく述べています 開放閉鎖原理(Open-Close Principle) は 今後のコラムで詳細に解説しますが 今回は簡単に紹介していておきます 開放閉鎖原理 (Open-Close Principle) クラス (or コンポーネント or モジュール ) は 拡張可能で開放されている こと かつ クラス (or コンポーネント or モジュール ) は 閉鎖されている のでクライアントから利 可能で あること 表 1-2 拡張可能で開放されている とは開発者がクラス (orコンポーネントorモジュール) 振る舞い ( 機能 ) を変更 ( 修正 ) できることを意味し 閉鎖されている とは クライアントがクラス (orコンポーネント orモジュール ) を利 できることを意味します 閉鎖されている については 設計レベルと実装レベルに分けて説明します クライアントは 図 1-2 のクラス client が該当します クラス supperclass の利 者です 拡張可能で開放されている ということが要求されるのはクラス supperclass です 設計レベルにおいて 閉鎖されている の意味は クラス supperclass のインタフェース( 操作 / メソッド / 関数 ) が安定 ( 修正が無い ) していて クラス client に対して修正が不要であることを意味します 実装レベルにおいて 閉鎖されている の意味は クラス supperclass がコンパイル可能で クラス client から利 可能できることを意味します Page 3

4 結局 この原則は 図 1-2 にクラス client に全く影響を与えず クラス supperclass の機能を修正あるいは拡張できると述べているのですが より具体的に えば 開放閉鎖原理 (Open-Close Principle) を遵守して設計と実装を う事で システム開発中あるいは出荷後のコードに対してソースコードを変更せずに機能修正や機能追加を うことができることを意味します つまり 試験中や動作中の既存ソースコードを変更せずに 機能修正や機能追加が可能になります おそらく初めて聞くときは そのようなことが可能なのか? と思うことでしょう 開放閉鎖原理(Open-Close Principle) に遵守するには クラス supperclass のインタフェース ( 操作 / メソッド / 関数 ) が変更をしては 開放閉鎖原理 (Open-Close Principle) を適 できません 開放閉鎖原理(Open-Close Principle) を適 するには クラス supperclass のインタフェース ( 操作 / メソッド / 関数 ) の名称やシグネイチャが変更されないという条件が付きます 開放閉鎖原理(Open-Close Principle) の理解と適 のポイントは継承にあります 図 1-2 でクラス supperclass には サブクラスが存在しています クラス supperclass のインタフェース ( 操作 / メソッド / 関数 ) が変更せず 機能拡張や機能の修正はサブクラスで実施するというものです さらに 開放閉鎖原理 (Open-Close Principle) の理解と適 で重要となるのは 別の重要な原理である 振る舞いタイプ( 型 ) 置換原理 を併 することになります 振る舞いタイプ ( 型 ) 置換原理 が理解できなと 開放閉鎖原理 (Open-Close Principle) を真の意味で使いこなすことは困難です なお 振る舞いタイプ ( 型 ) 置換原理 は 本コラムで別に機会に詳しく解説します Page 4

5 クラス client は影響を受けない 拡張可能で開放されている 同時に 閉鎖されている 図 1-2 機能の拡張はサブクラスで う それから 開放閉鎖原理 (Open-Close Principle) は コードの試験や構成管理のやり方にも影響を与えます 試験や構成管理作業も 開放閉鎖原理 (Open-Close Principle) と同調させることでより効果的な開発が可能となります 開放閉鎖原理 (Open-Close Principle) は単なる設計や実装のテクニックというよりも ソフトウエア開発作業全般に影響を与える原理となっています 試験および構成管理を含めた 開放閉鎖原理 (Open-Close Principle) に興味のある方は文献[1-2][1-3] を参照してください 今回は 開放閉鎖原理 (Open-Close Principle) についての紹介はここまでとします 開放閉鎖原理(Open-Close Principle) 価値を理解し 使いこなすには継承に対して もっと多くのことを理解する必要があります 後述する 表 1-6 にまとめてあります 今後 表 1-6 に登場する内容をコラムで解説する際に あらためて 開放閉鎖原理(Open-Close Principle) も一緒に詳しく解説します 実装継承と多重継承の効果 表 1-3 の内容は巷の書籍やセミナー トレーニングの継承の解説で良く かけます しかし継承の解説が少々単純すぎています もっと えは 表 1-3 の説明は間違いではないものの適切とも えないガイドラインです まだ継承になれていない方には良いかも知れません Page 5

6 巷でよく聞く継承関係のガイドライン 正しい継承関係は クラス間に is-a 関係あるいは kind-of 関係が成 するかどうかで判定する 実装継承 は is-a 関係あるいは kind-of 関係が成 しない間違った継承関係である 多重継承 は難しいので避け 委譲 (delegation) を いて単一継承で設計や実装をした方が良い 表 1-3 最も基本的となる継承に タイプ ( 型 ) 継承 (type inheritance) という種類があります この継承と対をなすのが 実装継承 (implementation inheritance) です 別の継承の分類として 単一継承 (single inheritance) と 多重継承(multiple inheritance) があります なお 本コラムをご覧なる方が まだ タイプ ( 型 ) 継承 (type inheritance) 実装継承 (implementation inheritance) 単一継承(single inheritance) 多重継承(multiple inheritance) についてご存知ない場合は 分かる範囲で読み進めて頂ければ結構です 第 3 回以降で科学的に継承を説明していく中で タイプ ( 型 ) 継承 (type inheritance) 実装継承(implementation inheritance) 単一継承(single inheritance) 多重継承(multiple inheritance) を解説します さて 多重継承 (multiple inheritance) や 実装継承(implementation inheritance) は 多くの場合あまり好ましく考えられていないようです 時には強く 多重継承 や 実装継承 を戒めている書籍やセミナー トレーニングもあるようで 多重継承 や 実装継承 は悪役の感じすら受けます C++ やEiffelには 多重継承 (multiple inheritance) のメカニズムがサポートされていますが Javaをはじめ多くのオブジェクト指向 語では 多重継承 (multiple inheritance) がサポートされていないことからも 多重継承 (multiple inheritance) があまり積極的に利 されない傾向にあることが分かります これは 語設計やコンパイラー作成が複雑になるという理由もありますが 最も きな理由は 語設計時の 多重継承 (multiple inheritance) に対する重要性を反映したものでしょう 一方 オブジェクト指向技術やプログラム 語の専門家達は 多重継承 や 実装継承 をどのように継承を捉えているのでしょうか? 実は専門家の中には 多重継承 や 実装継承 [ 注 1-2] は有 かつ重要と考えている人は多く存在します 開放閉鎖原理(Open-Close Principle) の紹介で登場したBertrand Meyerは 多重継承 や 実装継承 を極めて有 と考えている専門家です Page 6

7 Bertrand Meyerは彼の書著 ( 文献 [1-3]) の中で 彼独自の視点で 継承のテクニック の分類を掲載していいます ( 文献 [1-3] の第 24 章 ) この分類の中で, 継承を3つの きなグループに分け さらに12 個に分類し継承の使い方を特定していています Bertrand Meyerは12 個の継承の分類が全て有 と考えています ( 表 1-4 ) この12 個の分離の中に 多重継承 や 実装継承 を利 した継承が含まれています ただし この12 個に分類された継承を理解するには 表 1-6 の内容を理解しなければなりません また Bertrand Meyerの分類は Bertrand Meyerが設計したオブジェクト指向 語 Eiffelの機能を利 したときに可能な継承の分類になっています オブジェクト指向 語 Eiffelのメカニズムは 特性 (Eiffelではフィチャーと呼ぶ) ごとに細かな継承の設定が可能になる機能を持っています そのため JavaやC++や他のオブジェクト指向では直接実現することが困難な継承もあります Bertrand Meyerの継承の分類部分型継承 モデル継承 (model inheritance) ビュー継承 制約継承 拡張継承 具体化継承 構造継承 ソフトウエア継承 (software inheritance) 実装継承 定数継承 マシン継承 バリエーション (variation inheritance) ファンクショナルバリエーション継承 タイプ ( 型 ) バリエーション継承 無効化継承 表 1-4 Peter Wegnerも文献 [1-5] において 実装継承 に実 的な価値があると考えていることを述べている専門家です Bertrand Meyerは文献 [1-2] [1-3] の中で 多重継承 を持つことをオブジェクト指向 語の定義に含めており 多重継承 が極めて自然な継承である事を述べています Gilad BrachaとWilliam Cookは文献 [1-4] の中で 実装継承 の技法であるミックスイン [ 注 1-3] について 異なる複数のクラスから抽象的でないルーチンの集合を継承して新しい複雑なクラスを構築する能 がある と有効性を述べています Page 7

8 コードを再利 する目的の継承です そのため実装継承は コード継承 (code inheritance) とも呼ばれます スーパークラスとサブクラス間に 実装継承 (implementation inheritance) is-a 関係や a-kind-of 関係は必ずしも成 していません 別の い方をすればポリモフィズム ( 多相 / 多態 ) が出来ない継承ですより正確に えば タイプ置換原理 を満たさない継承となりますポリモフィズム ( 多相 / 多態 ) による利 をしなければ問題はありません 詳しい事は改めてコラムで解説しますミックスイン ( またはミキシンと呼ばれます ) は 多重継承により異なる複数のクラスから抽象的でないルーチン ( 操作 / 関数 ) の集合を継承して 新しい複雑なクラスを構築することが可能になりますミックスインで作成されたクラスはミキシンクラス (mixin class) と呼ばれます スーパークラスとサブクラスに間に 通常は is-a 関係や a-kind-of 関 ミックスイン ( ミキシン ) (mixin) 係は成 していません多くのクラス間には is-a 関係や a-kind-of 関係は成 しなくても 再利 できる機能 ( メソッド / 操作 / 関数 ) が点在しているので それらの機能を効果的に再利 する技法で コード作成の生産性と品質を向上することが可能です逆に えば 既に存在する似た機能が別のクラスの中にあるのに それを利 せず 同じ機能を複数実装することは冗 でありオブジェクト指向の精神に反するとも考えられますミックスインはプログラム 語の持つ継承や総称 ( ジェネリック / テンプレート ) などの機能に依存するので 語によって実装のメカニズムが異なる点は注意が必要です 表 1-5 科学的モデリング で継承を正確に理解する 科学的モデリング の視点で継承を正確に理解し 効果的に利 するには いくつかの重要な理論や定理等を学習する事が必要です 本コラムでは今後下記の重要事項を紹介しながら継承を解説していく予定です Page 8

9 継承に重要となる概念 理論 定理 原理 継承される特性 ( プロパティ ) の種類 タイプ ( 型 ) 安全な継承 クラスの 2 つの性質 タイプ ( 型 ) とモジュール タイプ ( 型 ) 置換原理 (substitute principle) 実装継承 (implementation inheritance) とタイプ ( 型 ) 継承 (type inheritance) 共変化 (co-variant) 逆変化 (contra-variant) 無変化 (no-variant) タイプ ( 型 ) の拡張 (extension) タイプ ( 型 ) の制限 (restriction) タイプ ( 型 ) 推論 (type reasoning) タイプ ( 型 ) の特殊化 (specialization) モジュラー推論 (modular reasoning) タイプ ( 型 ) の再定義 (override,redefine) 構文継承 (syntactic inheritance) 振る舞い継承 (behavior inheritance) 安全なコンポーネント設計 実装および再利 DesignByContract (DbC: 契約による設計 ) 継承を利 した原理群 参考文献 表 1-6 文献 [1-1] [Ian Joyner 1999] Objects Unencapsulated: Java, Eiffel and C++??( 邦訳 オブジェクト指 向 語のはなし ) 文献 [1-2] [Bertrand Meyer 1988] Object-Oriented Software Construction( 邦訳 オブジェクト 指向入門 ) 文献 [1-3] [Bertrand Meyer 1997] Object-Oriented Software Construction( 邦訳 オブジェクト 指向入門第 2 版 - 原則 コンセプト オブジェクト指向入門第 2 版 - 方法論 実践 ) 文献 [1-4] [Gilad Bracha and William Cook] Mixin-based Inheritance 文献 [1-5] [Peter Wegner 1991] Concepts and Paradigm of Object-Oriented Programming 文献 [1-6] [Erich Gamma, その他 1994]Design Patterns: Elements of Reusable Object- Oriented Software ( 邦訳 オブジェクト指向における再利 のためのデザインパターン ) Page 9