配置後の基本クラス デザインの変更
更新 : 2007 年 11 月
クラスの階層構造は、些細な変更でも予想外の結果を引き起こす可能性があるため、配置後には変更しないのが理想的です。しかし、現実には変更せざるを得ない場合もあります。たとえば、製品の要件が変更されたり、デザインの仕様に重要な要素が漏れていたりする場合などが考えられます。継承には、壊れやすい基本クラスの問題などの問題があります。
壊れやすい基本クラスの問題
継承階層を使用する場合の最大の欠点となるのが壊れやすい基本クラスという問題です。基本クラスを変更するときには、基本クラス、および派生クラスのすべてのコードの変更、再コンパイル、および再配布が必要になることがよくあります。基本クラスと派生クラスが複数の開発者によって作成されている場合は、この問題がさらに複雑になります。これは、それぞれの開発者が自分のソース コードへのアクセスを拒否する可能性があるためです。最悪の場合には、コンパイル済みバイナリ形式の更新された基本クラスを、それとは互換性がない元のバイナリ バージョンの派生クラスと一緒に使用するユーザーが出てきてしまいます。
たとえば、基本クラスのメンバのデータ型をオーバーライドしたり変更したりすると、派生クラスが使用できなくなる可能性があります。
壊れやすい基本クラスの問題への対策
壊れやすい基本クラスの問題を回避するための最善の方法は、派生クラスだけに変更を加えることです。しかし、基本クラスを最初にリリースする時点であらゆる可能性を考慮に入れる必要があるため、必ずしも可能ではありません。最善の努力を尽くしても、予想外の事態が発生して基本クラスの変更を余儀なくされることはあります。
MustInherit クラスと MustOverride メソッドを使用すると、実装の詳細が派生クラスに移り、基本クラスを変更する必要が少なくなるため、壊れやすい基本クラスの問題を軽減できます。しかし、この方法の場合でも、どれほど綿密な計画を立てても必ずしも可能とは限りません。
この他、派生クラスでシャドウされたデータ メンバを使用するのも有効です。この場合は、基本クラスのメンバとの名前の競合が起こりにくくなります。
基本クラスの機能を拡張するには、新しいメンバを追加するのが最も安全です。新しいメンバによって基本クラスが壊れてしまう可能性があるのは、派生クラスで Overloads キーワードを使用して基本クラスのメソッドを継承し、同じ名前の新しいメソッドを導入している場合だけです。この問題を回避するには、継承するメソッドを再定義して代わりに処理させることにより、継承する基本クラスのメソッドを派生クラスで明示的に指定します。
ある意味では、すべての基本クラスはある程度壊れやすいものです。結局のところ、壊れやすい基本クラスの問題を解消することはできません。しかし、できるだけ基本クラスを変更しなくても済むようにクラスの階層構造を慎重にデザインし、基本クラスを変更せざるを得ないときには徹底したテストを行うことで、この問題を最小限にとどめることはできます。