]多態性このページでは多態性のメリット、使用場面を説明します。メリットですが、まずは、よく言われるif文が無くなるという点についてはモジュールの凝集度と結合度の点から、もう少し詳しく説明します。多態性を使用しなければ出来ないこと(例えばイベント処理)がありますが、それについても説明します。多態性の使用場面としてはGoFのデザインパターンのうち多態性に関連するものを説明します。※このページを読むには、少なくともモジュールの凝集度、結合度について理解している必要があります。知らない人は先にそれらを理解してください。とたくさんあるのですが、特に理由は無いのですが、このページでは「多態性」で統一します。英語では「Polymorphism」なんだけど、こいつの読み方が、「ポリモーフィズム」と「ポリモルフィズム」といくつかあって面倒くさい。多態性とはオブジェクトのメソッドを呼び出したときに、その動作がオブジェクトの型によって変化するようにする仕組みのことです。下記のクラス図とサンプルソースを見てください。サンプルソースを実行するにはVBAのバージョンが6以上である必要があります。97を使用している方は実行できません。objs(i).printClassNameのところで、objs配列の中身を意識せずにprintClassNameメソッドを呼び出しています。結果(標準モジュールのmainメソッドの結果)はそれぞれのクラスモジュールで定義したprintClassNameメソッドの実装に沿った結果となっています。このページのトップへ2.多態性のメリット・デメリットまずは、よく言われるif文がなくなる点について説明します。VBAの場合、Object型を使用すると同じようなことが出来てしまうので説明がしにくい。Ifのようなソースを書かないといけなくなる。なると、そもそも、ソースの分量が増えるので読む気力がなくなってくる。命令網羅」でGoogleで調べてください。モジュールの凝集度について思い出して欲しいのだけど、これは論理的凝集度という感じがしている。(標準モジュール1の凝集度が悪くなってしまっていると思う。)また、Class0のサブクラスであるClass1、Class2、Class3と結合している点もまずいです。上記のIf文が1箇所しなかった場合はいいのだが、例えば1000箇所もあった場合にClass0のサブクラスが1つ増えたらどうしようか・・・。1000箇所修正するか・・・。そんなことをしたら、絶対修正漏れ起こすよ〜。多態性のメリットをまとめると、「Class0を使用する側のソースの分量を減らすことが出来る」「If分岐が減ることによりテストにかかる工数を減らすことが出来る」、「モジュールの凝集度を上げ、結合度を下げることが出来る」となります。次に、デメリットを説明する。本来ならClass1、Class2、Class3だけで良かったはずなのに、Class0が必要となっている点。要するに実装行数が増えてしまっているということ。以下の状況を考えて欲しい。後になってClass4が欲しくなりました。Class4.printClassNameの設計していると、実は引数が必要であることがわかりました(※1)。Class0のprintClassNameは引数が無いんだけど、どうするの?Class0のprintClassNameに引数を増やしてもいいけど、そうするとClass1、Class2、Class3のprintClassNameメソッドを修正しなくちゃいけないし、さらに、既に使用されている箇所(1000箇所もあったら大変だ)も修正しないといけない・・・。・・・と、後になって引数が足りないことに気がついたり、戻り値の型がおかしいことに気がついたりすることが多々ある・・・。そのようなことにならないよう、しっかり設計するのですが、しっかり設計するには工数がかかる。printClassNameの使用箇所が1000箇所もあれば、間違いなく多態性を使用したほうがいいのだけど、1箇所しかない場合は、多態性などしない方がよいです(※2)。多態性のメリット・デメリットをまとめると表1のようになります。多態性のメリット・デメリットのまとめ多態性のメリット多態性のデメリット■1.インタフェースを使用する側のソース量を減らすことが出来る。■2.インタフェースを使用する側のIf文の数が減らせ、テストにかかる工数を減らすことが出来る。■3.インタフェースを使用する側のモジュールの凝集度を高くできる。結合度を下げることが出来る。■4.インタフェースを使用する側は、インタフェースを実装するクラスが増えても修正する必要が無くなる。■1.インタフェースの分だけソース量が増える。■2.インタフェースの設計がいい加減だと、インタフェースを実装するクラスの種類が増えたときに対応できなくなる。■3.2を回避するため、インタフェースの設計にとにかく工数がかかる。守れなくなることがわかりました」。」の下記の場所にも書かれています。適用できない状況)このページのトップへ3.多態性を利用しないと出来ないこと多態性を利用しないと出来ないことがある。その場合は多態性を使用するしかない。多態性を利用しないといけない場合というのは、主にフレームワークを作成している場合、および、フレームワークを使用している場合です。具体的にはイベント処理(一般的にはオブザーバパターンで実装。VBA(Ver.6以上)の場合は特別に構文がある)かな。他にもあるかもしれませんが、これくらいで。多態性の使用場面ですが、GoFのデザインパターンのうち、多態性が関係していると思われるものを紹介します。GoFのデザインパターンは23個しかないんだけど、多態性が関係しているものがかなりあり、紹介しきれません(※1)。■オブザーバパターンGUIなど(例えば、java.awtパッケージ)のイベント処理の部分で使用されるデザインパターンです。フレームワーク側でイベント用のインタフェースを定義しておき、フレームワークを使用する側で、インタフェースを実装するクラスの作成をします。■ストラテジーパターン戦略がいくつかあり、それらを切り替えたりしたいときなどに使用するデザインパターンです。暗号化処理について考えてみてください。暗号のアルゴリズム(ここでは共通鍵暗号方式(※2)とします)にはDESやAESなどがありますが、いずれ、破られて使用できなくなる可能性があります。その際、暗号化アルゴリズムを別の(まだ破られていない)アルゴリズムに簡単に切り替えられるようになっていれば修正が楽ですね。実際、例えば、Java(java.securityパッケージ)ではどうだろうか・・・。他のデザインパターンも使用していそうだ。■ステートパターンオブジェクトの状態によってメソッドの動作が変わるようにしたいときに使用されるデザインパターンです。1つの状態を1つのクラスとして定義しておきます。■インタプリタパターンあまり使うことは無いかもしれませんが、簡単に言うと構文解析をしたいときに使用するデザインパターンです。■テンプレートメソッドパターン■コマンドパターン...関係あるっぽいよ。-----※1:だるまが調べきれないため。※2:暗号化するときと、暗号化されたものを戻す(複合化)ときに同じキーを使用する暗号方式。このページのトップへ5.参考文献などもっと勉強したい人は下記も読んでみて下さい。GoFのデザインパターンを紹介しています。多態性について簡単に説明しています。978-4797327038このページのトップへこのページの利用によって発生した、いかなる損害について、このホームページの作成者は責任を負いません。このページの間違いや嘘を見つけた方、このページに書いて欲しい情報がある方はメールをお願いします。Corporationの米国およびその他の国における登録商標または商標です。VBAと表記する場合があります。Computer,Inc.の登録商標または商標です。米国およびその他の国における商標または登録商標です。その他、社名および商品名、システム名称などは、一般に各社の商標または登録商標です。このホームページの作成者はこれらの会社とはいっさい関係がありません。