クラスはオブジェクト指向プログラミングにおいて重要ですが、設計が不十分だと問題のあるコードにつながる可能性があります。

クリーンコード 第 10 章では、単一の責任を持つ凝集したクラスの重要性を強調しています。

この記事では、重要な洞察を共有し、JavaScript での応用例を示します。

?クラスの結束力とは何ですか?

凝集性とは、クラスの責任がどの程度密接に関連しているかを指します。

まとまりのあるクラスでは、単一の目的に焦点を当て、責任が自然に調和します。

これにより、クラスがシンプルで読みやすく、保守しやすくなります。

例: 低凝集性

class User {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }

  // Handles user registration
  register() {
    // Registration logic
  }

  // Sends email to user
  sendEmail(message) {
    // Email sending logic
  }

  // Logs activity of the user
  logActivity(activity) {
    console.log(`${this.name} performed: ${activity}`);
  }
}

上記の例では、User クラスには、ユーザー登録、電子メールの送信、アクティビティのログ記録という 3 つの無関係な役割があります。

このクラスは、あまりにも多くのことを同時に実行しようとするため、一貫性に欠けています。

?単一責任原則 (SRP)

単一責任原則は、クラスが変更する理由は 1 つだけであるべきであると述べています。これは、各クラスが 1 つの関心事に焦点を当てる必要があることを意味します。

クラスに複数の責任がある場合、ある領域を変更すると、別の領域の機能が損なわれる可能性があります。

⚡️ SRP のリファクタリング

SRP に準拠するように上記の例をリファクタリングしましょう:

class User {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }
}

class UserRegistrationService {
  register(user) {
    // Registration logic
  }
}

class EmailService {
  sendEmail(user, message) {
    // Email sending logic
  }
}

class ActivityLogger {
  logActivity(user, activity) {
    console.log(`${user.name} performed: ${activity}`);
  }
}

各クラスには 1 つの責任があります:

• ユーザー: ユーザー オブジェクトを表し、データを保持します。
• UserRegistrationService: ユーザー登録を処理します。
• EmailService: 電子メールの送信を処理します。
• ActivityLogger: ユーザー アクティビティのログ記録を処理します。

この構造では、電子メール システムへの変更はユーザー登録ロジックに影響しません。また、その逆も同様です。

? SRP と結束力の利点

• 保守性: クラスの責任が 1 つであれば、バグを見つけて修正するのが簡単になります。無関係なロジックを読み進める必要はありません。

• スケーラビリティ: プロジェクトが成長するにつれて、SRP に準拠すると、新しい機能の追加が簡単になります。既存のクラスに手を加えずに、新しいクラスに新しい機能を追加できます。

• テスト容易性: 単一の責任を持つクラスはテストが容易です。各クラスの範囲は限られているため、単体テストでは個々の機能に焦点を当てることができます。

?責任の重複を特定する

クラスの一貫性を確保するには、複数の責任が組み合わされている領域を探します。

多くの場合、クラスは単純に始まりますが、機能が追加されるにつれて、余分な義務が蓄積される可能性があります。

例: 支払いシステムのリファクタリング

複数のタスクを処理する PaymentProcessor クラスがあるとしましょう:

class PaymentProcessor {
  constructor() {
    this.paymentGateway = new PaymentGateway();
  }

  processPayment(paymentDetails) {
    // Payment processing logic
  }

  validatePaymentDetails(paymentDetails) {
    // Validation logic
  }

  logTransaction(paymentDetails) {
    console.log(`Payment processed: ${JSON.stringify(paymentDetails)}`);
  }
}

ここで、PaymentProcessor は、支払いの処理、詳細の検証、トランザクションのログ記録を担当します。

これはリファクタリングと責任の分担を行う機会です:

class PaymentProcessor {
  constructor(paymentGateway, validator, logger) {
    this.paymentGateway = paymentGateway;
    this.validator = validator;
    this.logger = logger;
  }

  processPayment(paymentDetails) {
    if (this.validator.isValid(paymentDetails)) {
      this.paymentGateway.process(paymentDetails);
      this.logger.logTransaction(paymentDetails);
    }
  }
}

class PaymentValidator {
  isValid(paymentDetails) {
    // Validation logic
    return true; // Simplified for example
  }
}

class PaymentLogger {
  logTransaction(paymentDetails) {
    console.log(`Payment processed: ${JSON.stringify(paymentDetails)}`);
  }
}

PaymentProcessor クラスには、支払いの処理という 1 つの役割があります。

検証とログは別のクラス (PaymentValidator と PaymentLogger) に移動されました。

⚡️結論

クラスを一貫性を持って設計し、単一責任の原則に準拠することで、コードベースの柔軟性、保守性、理解しやすさが確保されます。

責任を個別の焦点を絞ったクラスに分割することで、個々のコンポーネントの複雑さが軽減され、システムがより堅牢になります。

JavaScript では、大規模なフレームワークやアプリケーションでクラスがよく使用されるため、これらの原則に従うとコードの品質が大幅に向上します。

『クリーン コード』の本で説明されているように、クリーンなクラスを書くことは、単にコードを整理することではなく、メンテナンスが悪夢にならずに進化できるシステムを作成することです。

ハッピーコーディング!