SOLIDE : S – Principe de responsabilité unique (SRP)

Introduction au SRP :
Le principe de responsabilité unique (SRP) est l'un des cinq principes SOLID, un ensemble de lignes directrices pour écrire du code plus propre et plus durable. SRP stipule qu'une classe ne devrait avoir qu'une seule raison de changer, ce qui signifie qu'elle ne devrait avoir qu'une seule responsabilité ou fonction. Suivre ce principe rend le code plus facile à comprendre, à maintenir et à tester.

Objectifs du SRP :

• Maintenance simplifiée :Les classes n'ayant qu'une seule responsabilité, l'identification et la correction des bugs deviennent plus faciles.
• Responsabilité claire : Chaque classe a un objectif clair, ce qui rend le code plus facile à comprendre.
• Testabilité améliorée : Les classes avec des responsabilités uniques sont plus faciles à isoler et à tester.
• Facilité de changement : Les changements dans une responsabilité spécifique n'affectent pas les autres parties du système.

Exemple de mauvaise pratique (cours) :
Ici, nous avons une classe UserService qui fait plus d'une chose : gère les utilisateurs et envoie des notifications.

class UserService {
  createUser(user: User): void {
    // Logic to create user
  }

  deleteUser(userId: string): void {
    // Logic to delete user
  }

  notifyUser(userId: string, message: string): void {
    // Logic to notify user
  }
}

Dans cette approche, la classe UserService a de multiples responsabilités : gérer les utilisateurs et envoyer des notifications. Cela viole le SRP.

Exemple de bonne pratique (cours) :
Pour appliquer le SRP, nous pouvons séparer les responsabilités en classes distinctes.

class UserService {
  createUser(user: User): void {
    // Logic to create user
  }

  deleteUser(userId: string): void {
    // Logic to delete user
  }
}

class NotificationService {
  notifyUser(userId: string, message: string): void {
    // Logic to notify user
  }
}

Désormais, UserService gère uniquement la création et la suppression d'utilisateurs, tandis que NotificationService gère les notifications. Chaque classe a une seule responsabilité, selon le SRP.

Exemple de mauvaise pratique (fonctions) :
Ici, nous avons une fonction qui fait plus d'une chose : crée un utilisateur et envoie une notification.

function createUserAndNotify(user: User, message: string): void {
  // Logic to create user
  // Logic to send notification
}

Dans cette approche, la fonction createUserAndNotify a de multiples responsabilités : créer un utilisateur et envoyer une notification. Cela viole le SRP.

Exemple de bonne pratique (Fonctions) :
Pour appliquer le SRP, on peut séparer les responsabilités en fonctions distinctes.

function createUser(user: User): void {
  // Logic to create user
}

function notifyUser(userId: string, message: string): void {
  // Logic to notify user
}

// Using the separated functions
createUser(newUser);
notifyUser(newUser.id, 'Welcome!');

Désormais, la fonction createUser gère uniquement la création d'utilisateurs, tandis que notifyUser gère les notifications. Chaque fonction a une seule responsabilité, selon SRP.

Application en React Native avec TypeScript :
Imaginez que nous développons une application de gestion de tâches. Nous pouvons appliquer SRP en séparant la logique de gestion des tâches et la logique de notification en différentes classes.

Exemple de mauvaise pratique (cours) :

class TaskService {
  addTask(task: Task): void {
    // Logic to add task
  }

  removeTask(taskId: string): void {
    // Logic to remove task
  }

  notifyTaskDue(taskId: string): void {
    // Logic to notify that the task is due
  }
}

Exemple de bonne pratique (cours) :

class TaskService {
  addTask(task: Task): void {
    // Logic to add task
  }

  removeTask(taskId: string): void {
    // Logic to remove task
  }
}

class TaskNotificationService {
  notifyTaskDue(taskId: string): void {
    // Logic to notify that the task is due
  }
}

Exemple de mauvaise pratique (fonctions) :

function addTaskAndNotify(task: Task): void {
  // Logic to add task
  // Logic to notify that the task is due
}

Exemple de bonne pratique (Fonctions) :

function addTask(task: Task): void {
  // Logic to add task
}

function notifyTaskDue(taskId: string): void {
  // Logic to notify that the task is due
}

// Using the separated functions
addTask(newTask);
notifyTaskDue(newTask.id);

En divisant les responsabilités, nous facilitons la maintenance et l'extension de l'application.

Conclusion :
Le respect du principe de responsabilité unique permet de garder le code propre, organisé et plus facile à maintenir. L'application de SRP dans le développement React Native avec TypeScript permet d'obtenir un code plus modulaire et testable. N'oubliez jamais de concentrer vos cours et fonctions sur une seule responsabilité pour récolter tous les bénéfices de ce principe.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!