クラス継承と抽象化設計：レビューアーが検出すべき設計臭とは
はじめに
Pythonのオブジェクト指向設計において、クラス継承と抽象化は強力な表現手段です。しかしそれは同時に、設計の歪みや責務の混濁がもっとも現れやすい領域でもあります。レビューアーは、その歪みが生み出す“設計臭（Design Smell）”を嗅ぎ取り、構造的に検出する視点を持たなければなりません。
本稿では、継承構造のどこを見れば「危うい抽象化」に気づけるのか、レビュー時のポイントを実例と図解を交えて整理します。
継承が過剰になる構造的背景
継承を導入する際、多くの開発者は次のような動機を抱いています：
- コードの再利用を図るため
- APIの一貫性を保つため
- “○○は××である”というIS-A関係を表現するため
しかしこの動機に対し、以下のようなコードを見かけることがあります。
class UserDataExporter:
def export_csv(self, data): ...
def export_json(self, data): ...
class ProductDataExporter(UserDataExporter):
def export_xml(self, data): ...
@ReviewerProductDataExporter が UserDataExporter を継承しているのは「CSV/JSONのエクスポート機能を借りたいから」という再利用目的であり、本来の“IS-A”関係ではありません。**委譲（composition）**による分離設計が適していると判断できます。
このように、「継承＝再利用」という短絡的な判断が、設計臭の原因になります。
継承（inheritance）は親クラスの属性・振る舞いを引き継ぐ手段であり、「○○は××である（IS-A）」関係で使うべき設計手法です。一方、委譲（composition）は「○○は××を含む（HAS-A）」構造で、柔軟かつ安全な責務分離が可能になります。
実例：不適切な抽象基底クラスの設計臭
抽象クラスを使った設計にも、しばしば次のような構造的問題が見られます。
from abc import ABC, abstractmethod
class NotificationSender(ABC):
@abstractmethod
def send_email(self, recipient, content):
pass
class SlackSender(NotificationSender):
def send_slack(self, channel, message):
...
@Reviewer`NotificationSender` の抽象基底クラスに `send_email` があるのに、SlackSender では `send_slack` だけが定義されている。**抽象化の軸がブレており、継承の設計が成立していません。**
このような場合は、送信手段ごとにインターフェースを分割する（Interface Segregation）ことで、より健全な設計に改善できます。
レビューでは「全サブクラスが本当に共通して実装すべき機能か？」という視点から、抽象クラスやProtocolの設計を精査します。
継承と委譲の対比図
この図では、CsvAndJsonExporter が委譲によって CsvExporter と JsonExporter を利用しています。継承ではなく委譲を用いることで、責務の明示性が向上しています。
判別ポイント：継承構造レビューの観点
レビュー時に次の観点をチェックすることで、設計臭を的確に検出できます。
| 観点 | チェック内容 |
|---|---|
| IS-A関係の適合性 | 本当に「～である」と言える関係か |
| 抽象メソッドの一貫性 | サブクラスで意味をなす抽象定義か |
| メソッドのオーバーライド頻度 | 全部オーバーライドしていないか |
| 複数継承構造の有無 | MROに依存する危険な構造がないか |
| 親クラスの責務の粒度 | 複数の関心事を抱えていないか |
継承と抽象化の設計臭は、構文エラーとして表面化しません。レビューアーの観察力と構造把握能力が鍵となります。
まとめ
Pythonにおけるクラス継承や抽象化は、柔軟な表現力を持つ一方で、設計の意図が曖昧になると大きな負債につながります。レビューアーは次のような視点を持って、設計臭の検出に取り組む必要があります。
- 継承か委譲かの構造判断
- 抽象クラスが持つべき最低限の責務設計
- IS-A関係の成否判定
- 抽象性の適切な粒度と分離
レビューアー自身が“抽象化の意図を読む力”を持ち、それを設計者に返すことで、設計の質は大きく改善されます。