クリーンなコードを理解する: クラス ⚡️-jsチュートリアル-php.cn

クリーンなコードを理解する: クラス ⚡️

王林

リリース： 2024-09-10 11:09:02

オリジナル

888 人が閲覧しました

Understanding Clean Code: Classes ⚡️

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

クリーンコードの第 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 に準拠すると、新しい機能の追加が簡単になります。既存のクラスに手を加えずに、新しいクラスに新しい機能を追加できます。
テスト容易性: 責任が 1 つのクラスはテストが容易です。各クラスの範囲は限られているため、単体テストでは機能の個々の部分に焦点を当てることができます。

?責任の重複を特定する

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

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

例: 決済システムのリファクタリング

複数のタスクを処理する 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) に移動されました。