„Wenn ein Arbeiter seine Arbeit gut machen will, muss er zuerst seine Werkzeuge schärfen.“ – Konfuzius, „Die Gespräche des Konfuzius. Lu Linggong“
Titelseite > Programmierung > SOLID: S – Single-Responsibility-Prinzip (SRP)

SOLID: S – Single-Responsibility-Prinzip (SRP)

Veröffentlicht am 20.08.2024
Durchsuche:697

SOLID: S - Single Responsibility Principle (SRP)

Einführung in SRP:
Das Single-Responsibility-Prinzip (SRP) ist eines der fünf SOLID-Prinzipien, eine Reihe von Richtlinien zum Schreiben von saubererem und nachhaltigerem Code. SRP besagt, dass eine Klasse nur einen Grund zur Änderung haben sollte, was bedeutet, dass sie nur eine Verantwortung oder Funktion haben sollte. Wenn Sie diesem Prinzip folgen, ist der Code leichter zu verstehen, zu warten und zu testen.

Ziele von SRP:

  • Vereinfachte Wartung: Da Klassen nur eine Verantwortung haben, wird die Identifizierung und Behebung von Fehlern einfacher.
  • Klare Verantwortung: Jede Klasse hat einen klaren Zweck, wodurch der Code leichter verständlich ist.
  • Verbesserte Testbarkeit: Klassen mit einzelnen Verantwortlichkeiten lassen sich einfacher isolieren und testen.
  • Einfache Änderung: Änderungen in einer bestimmten Verantwortung wirken sich nicht auf andere Teile des Systems aus.

Bad Practice-Beispiel (Klassen):
Hier haben wir eine UserService-Klasse, die mehr als eine Aufgabe erfüllt: Benutzer verwaltet und Benachrichtigungen sendet.

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
  }
}

Bei diesem Ansatz hat die UserService-Klasse mehrere Verantwortlichkeiten: Benutzer verwalten und Benachrichtigungen senden. Dies verstößt gegen SRP.

Good-Practice-Beispiel (Kurse):
Um SRP anzuwenden, können wir die Verantwortlichkeiten in verschiedene Klassen unterteilen.

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
  }
}

Jetzt verarbeitet UserService nur das Erstellen und Löschen von Benutzern, während NotificationService Benachrichtigungen verarbeitet. Jede Klasse hat gemäß SRP eine einzige Verantwortung.

Bad Practice-Beispiel (Funktionen):
Hier haben wir eine Funktion, die mehr als eine Sache tut: einen Benutzer erstellt und eine Benachrichtigung sendet.

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

Bei diesem Ansatz hat die Funktion „createUserAndNotify“ mehrere Aufgaben: Erstellen eines Benutzers und Senden einer Benachrichtigung. Dies verstößt gegen SRP.

Good-Practice-Beispiel (Funktionen):
Um SRP anzuwenden, können wir die Verantwortlichkeiten in verschiedene Funktionen aufteilen.

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!');

Jetzt verarbeitet die Funktion „createUser“ nur die Benutzererstellung, während „notifyUser“ Benachrichtigungen verarbeitet. Jede Funktion hat gemäß SRP eine einzige Verantwortung.

Anwendung in React Native mit TypeScript:
Stellen Sie sich vor, wir entwickeln eine Aufgabenverwaltungs-App. Wir können SRP anwenden, indem wir die Aufgabenverwaltungslogik und die Benachrichtigungslogik in verschiedene Klassen unterteilen.

Bad Practice-Beispiel (Klassen):

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
  }
}

Good-Practice-Beispiel (Kurse):

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
  }
}

Bad Practice-Beispiel (Funktionen):

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

Good-Practice-Beispiel (Funktionen):

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);

Durch die Aufteilung der Verantwortlichkeiten erleichtern wir die Wartung und Erweiterung der Anwendung.

Abschluss:
Das Befolgen des Single-Responsibility-Prinzips trägt dazu bei, den Code sauber, organisiert und einfacher zu warten. Die Anwendung von SRP in der React Native-Entwicklung mit TypeScript führt zu modularerem und testbarerem Code. Denken Sie immer daran, Ihre Kurse und Funktionen auf eine einzige Verantwortung zu konzentrieren, um alle Vorteile dieses Prinzips zu nutzen.

Freigabeerklärung Dieser Artikel ist abgedruckt unter: https://dev.to/paulocappa/solid-day-1-s-single-responsibility-principle-srp-1f5k?1 Bei Verstößen wenden Sie sich bitte an [email protected], um ihn zu löschen Es
Neuestes Tutorial Mehr>

Haftungsausschluss: Alle bereitgestellten Ressourcen stammen teilweise aus dem Internet. Wenn eine Verletzung Ihres Urheberrechts oder anderer Rechte und Interessen vorliegt, erläutern Sie bitte die detaillierten Gründe und legen Sie einen Nachweis des Urheberrechts oder Ihrer Rechte und Interessen vor und senden Sie ihn dann an die E-Mail-Adresse: [email protected] Wir werden die Angelegenheit so schnell wie möglich für Sie erledigen.

Copyright© 2022 湘ICP备2022001581号-3