Item 34: Differentiate between inheritance of interface and inheritance of implementation
前回: Effective C++読書メモ #33
前回は、複数スコープをまたぐ名前解決ポリシーと、それと付き合っていくためのusingキーワード利用およびforwarding function作成の話だった。
今回は、インタフェースの継承と実装の継承を使い分けるべきという話。基本的にはタイトルの通りで、pure virtual / virtual / 非virtualの使い分けとそれによって得られるものについて。
全メンバーが非virtualなのはヤバそうなクラス設計の兆候。
全メンバーがvirtualなのも同様。これは良い設計である場合もあるけど、単純にクラス設計者の考慮漏れという可能性もあるため、という締め。
前回: Effective C++読書メモ #33
前回は、複数スコープをまたぐ名前解決ポリシーと、それと付き合っていくためのusingキーワード利用およびforwarding function作成の話だった。
今回は、インタフェースの継承と実装の継承を使い分けるべきという話。基本的にはタイトルの通りで、pure virtual / virtual / 非virtualの使い分けとそれによって得られるものについて。
- pure virtualな関数宣言による継承クラスでの個別実装強要
- なおpure virtualな関数宣言に加えてその実装を基底クラス側でおこなうこともできる。継承クラス側で基底クラス名での修飾をおこなわない限り呼び出せないので有用性低いように思える(伏線)
- pureではないvirtualな関数宣言によるデフォルト実装の提供と、継承クラスでの上書き許容
- 継承クラスで暗黙的にデフォルト実装を利用したらまずいケース
- pure virtualな関数宣言とprotectedな別名のデフォルト実装を提供することで、継承クラス側にて明示的に親の提供するデフォルト実装を指定できる
- こうすると名前空間のなかにごちゃごちゃと類似機能のメソッドを増やすことになるのが嫌という考えもある
- その際は、前述のpure virtualな関数宣言+実装を基底クラス側でおこなっておき、継承クラス側では明示的にその実装を呼び出す策が使える
全メンバーが非virtualなのはヤバそうなクラス設計の兆候。
全メンバーがvirtualなのも同様。これは良い設計である場合もあるけど、単純にクラス設計者の考慮漏れという可能性もあるため、という締め。
0 件のコメント:
コメントを投稿