ソースコードでのクラス・メソッドの分割粒度

ソースコードにおけるクラスやメソッドの適切な分割粒度は、ソフトウェアの保守性と拡張性を大きく左右します。以下では、この分割粒度のベストプラクティスについて具体例を交えて詳しく説明します。

1. 単一責任の原則 (Single Responsibility Principle)

クラスは1つの具体的な責務しか持たないようにする
例えば、データベース接続クラスとデータ処理クラスは分離する

2. コヒーション (Cohesion)

クラス内のメソッドは密接に関連した機能を持つべき
無関係なロジックは別のクラスに分割する
例: UserManagerにグループ管理機能を含めるのは不適切

3. メソッドサイズ

メソッドの行数が多すぎると可読性が低下する
10~20行を超えるメソッドは分割を検討する
例:

  # メソッドが長すぎる
  def apply_discounts(order, customer):
    # ...割引ロジック100行...
    return order

  # 適切に分割する  
  def apply_discounts(order, customer):
    discounts = get_applicable_discounts(customer)
    order.total = calc_discounted_total(order, discounts)
    return order

4. インデントレベル

ネストが深すぎるとコードが複雑になり可読性が下がる
3レベル以上のネストは別メソッドに分割検討する

5. 情報の隠蔽 (Information Hiding)

クラスの内部実装を隠蔽し、インターフェースのみ公開する
例: プライベートメソッドの活用、ファイル/ディレクトリ分割

6. ファイル/ディレクトリ構造

関連するクラスは同じディレクトリに置く
1ファイルに複数のクラスを含めるのは避ける

7. 名前付け

適切な名前でクラス/メソッドの責務が推測できるよう心がける

これらの原則を守ることで、保守性の高いモジュール性の高いコードが書けます。一方で、過度な分割は複雑性を増すため、適切なバランスが重要です。コンポーネントの粒度が大きすぎれば変更が難しく、小さすぎれば全体の把握が難しくなります。

設計段階から適切な分割を意識し、継続的にリファクタリングを行うことで、柔軟で保守性の高いシステムを構築できるでしょう。また、コードレビューでこの観点からのフィードバックを行うのも有効な方法です。