🚀 ニフティ’s Notion

これは、まだ 📄 【オブジェクト指向2025 #6】お題: サブスク管理システムを作ろう のあとリファクタリングをしていない世界の後日譚…

def subscribe(mail_address: str, plan_id: int):
    "申し込む"

    # なんやかんやプラン情報を取得して準備する
    price = get_price(plan_id)
    subscription = Subscription(plan_id, price)
    rate_discount = get_rate_discount()
    subscription.rate_discount(rate_discount)  # 20% OFF

    # 申込情報をデータベースに保存
    save_to_database(subscription)

    # メール送信
    message = f"{subscription.monthly_price()}円で購読ありがとうございます"
    send_mail_to(mail_address, message)

〜 数日後 〜

結局、Aさんは苦肉の策でこのように実装することに。

# テスト実行時は really_send_mail を False にすること
def subscribe(really_send_mail: bool, mail_address: str, plan_id: int):
    # ...

    # メール送信
    if really_send_mail:
        message = f"{subscription.monthly_price()}円で購読ありがとうございます"
        send_mail_to(mail_address, message)

この対策は、本来の申込処理に必要な情報 (メールアドレスやプラン) とテストのためだけに必要な情報 (本当にメールを送るかどうか) を区別できない形で混ぜ込んでしまっていて、ロジックの見通しの良さや保守性が低下してしまう。

1. 申込処理の中に、外の世界に影響を及ぼすモジュールへの直接的な依存を含めてしまったこと。
   • これにより著しく再利用性が下がってしまい、テスト実行ができなくなった

実は、これは後で説明するSOLID原則の「D: 依存性逆転の法則」が有効なケースです。

→ メール送信機能を状況によって 外からつけ外しできるように する。