Beherrschung des DRY-Prinzips: Anwendung von Design Patterns in C# für sauberen Code

Schritte und Beispiel:

1. Anfangscode: Die Logik für die Generierung der Mitarbeiter-ID befand sich direkt im Click-Event-Handler einer Schaltfläche.

   

2. Refactored Code: Tim verbessert die Methode, indem er sie flexibler macht. Anstatt sich auf spezifische UI-Elemente zu verlassen, akzeptiert die Methode jetzt firstName und lastName als Parameter und gibt die generierte ID zurück. Durch diese Änderung kann die Methode in verschiedenen Kontexten und UI-Elementen verwendet werden:

   private string GenerateEmployeeID(string firstName, string lastName)
   {
     string employeeID = firstName.Substring(0, 4) + lastName.Substring(0, 4) + DateTime.Now.Millisecond.ToString();
     return employeeID;
   }

   private string GenerateEmployeeID(string firstName, string lastName)
   {
     string employeeID = firstName.Substring(0, 4) + lastName.Substring(0, 4) + DateTime.Now.Millisecond.ToString();
     return employeeID;
   }

   Anschließend demonstriert Tim, wie diese Methode über das Klick-Ereignis aufgerufen wird:

   employeeIdText.Text = GenerateEmployeeID(firstNameText.Text, lastNameText.Text);

   employeeIdText.Text = GenerateEmployeeID(firstNameText.Text, lastNameText.Text);

   Er weist auch darauf hin, dass diese Methode nun auch in anderen Teilen der Anwendung verwendet werden kann, z. B. bei der Verarbeitung von CSV-Dateien mit mehreren Mitarbeiterdatensätzen, ohne den Code zu wiederholen.

Schritte und Beispiel:

1. Erstellung der Klassenbibliothek:

   • Tim (9:47) erstellt ein neues Klassenbibliotheksprojekt in .NET Framework und benennt es DRYDemoLibrary.

   • Innerhalb dieser Bibliothek definiert er eine öffentliche Klasse EmployeeProcessor und verschiebt die GenerateEmployeeID Methode in diese Klasse:

     public class EmployeeProcessor
     {
      public string GenerateEmployeeID(string firstName, string lastName)
      {
         string employeeID = firstName.Substring(0, 4) + lastName.Substring(0, 4) + DateTime.Now.Millisecond.ToString();
         return employeeID;
      }
     }

     public class EmployeeProcessor
     {
      public string GenerateEmployeeID(string firstName, string lastName)
      {
         string employeeID = firstName.Substring(0, 4) + lastName.Substring(0, 4) + DateTime.Now.Millisecond.ToString();
         return employeeID;
      }
     }

2. Verwendung der Klassenbibliothek in Projekten:

   • In seinen WinForms- (13:18) und WPF-Projekten (14:00) fügt Tim einen Verweis auf die Klassenbibliothek DRYDemoLibrary hinzu.

   • Er ersetzt dann den alten Code durch Aufrufe der GenerateEmployeeID Methode aus der Klassenbibliothek:

     EmployeeProcessor processor = new EmployeeProcessor();
     employeeIDText.Text = processor.GenerateEmployeeID(firstNameText.Text, lastNameText.Text);

     EmployeeProcessor processor = new EmployeeProcessor();
     employeeIDText.Text = processor.GenerateEmployeeID(firstNameText.Text, lastNameText.Text);

   • Durch diesen Ansatz wird Redundanz vermieden, da die Methode nun an einer einzigen Stelle gepflegt wird. Tim zeigt, dass dieselbe Klassenbibliothek in verschiedenen UI-Frameworks (WinForms und WPF) verwendet werden kann, ohne den Code zu wiederholen.

3. Vorteile:

   • Konsistenz: Durch die Zentralisierung der Logik in einer Klassenbibliothek stellt Tim sicher, dass Änderungen an der Logik (z. B. Fehlerbehebungen) in allen Projekten einheitlich angewendet werden.

   • Reduzierte Wartung: Änderungen an der Methode müssen nur in der Klassenbibliothek vorgenommen werden, um Inkonsistenzen zu vermeiden und den Wartungsaufwand zu verringern.

Schritte und Beispiel:

1. Erstellung einer neuen Lösung und eines neuen Projekts:

   • Tim (17:29) beginnt mit der Erstellung einer neuen Lösung für eine Konsolenanwendung und simuliert ein Szenario, in dem Sie die DRYDemoLibrary in einer anderen Art von Projekt, wie einem Windows-Dienst oder einer Konsolenanwendung, verwenden müssen.

   • Er nennt das neue Projekt ConsoleUI und zeigt, wie man eine einfache Konsolenanwendung einrichtet.

     class Program
     {
      static void Main(string[] args)
      {
         Console.ReadLine();
      }
     }

     class Program
     {
      static void Main(string[] args)
      {
         Console.ReadLine();
      }
     }

2. Hinzufügen einer Referenz zur Klassenbibliothek:

   • Tim erklärt, wie man einen Verweis auf die DRYDemoLibrary DLL in das neue Projekt einfügt. Dazu muss die DLL-Datei im bin-Ordner des Klassenbibliotheksprojekts aufgerufen und der Konsolenanwendung hinzugefügt werden.

     using DRYDemoLibrary;

     using DRYDemoLibrary;

   • Sobald die Referenz hinzugefügt ist, verwendet Tim (19:24) die EmployeeProcessor-Klasse aus der Bibliothek, um eine Mitarbeiter-ID auf der Grundlage von Benutzereingaben zu generieren.

     Console.WriteLine("What is your first name?");
     string firstName = Console.ReadLine();
     
     Console.WriteLine("What is your last name?");
     string lastName = Console.ReadLine();
     
     EmployeeProcessor processor = new EmployeeProcessor();
     string employeeID = processor.GenerateEmployeeID(firstName, lastName);
     
     Console.WriteLine($"Your employee ID is {employeeID}");

     Console.WriteLine("What is your first name?");
     string firstName = Console.ReadLine();
     
     Console.WriteLine("What is your last name?");
     string lastName = Console.ReadLine();
     
     EmployeeProcessor processor = new EmployeeProcessor();
     string employeeID = processor.GenerateEmployeeID(firstName, lastName);
     
     Console.WriteLine($"Your employee ID is {employeeID}");

3. Ausführen der Konsolenanwendung:

   • Tim demonstriert, wie die Konsolenanwendung ausgeführt wird, um zu zeigen, dass die Mitarbeiter-ID mithilfe der Bibliothek erfolgreich generiert wird. Dies bestätigt, dass derselbe Code aus der Klassenbibliothek in verschiedenen Projekten wiederverwendet werden kann.

     

4. Aktualisierung der DLL:

   • Tim erwähnt kurz, dass Sie die DLL in den Projekten, die sie referenzieren, aktualisieren können, wenn sich diese ändert. Er weist darauf hin, dass die Verwendung von NuGet-Paketen ein empfehlenswerter Ansatz für die Verwaltung und Aktualisierung von DLLs über mehrere Projekte hinweg ist, auch wenn dieses Video nicht im Detail darauf eingeht.

Wichtige Punkte:

1. Erstellen eines NuGet-Pakets:

   • Anstatt DLL-Dateien manuell zu verwalten, schlägt Tim vor, ein NuGet-Paket für die Klassenbibliothek zu erstellen. Dazu muss die DLL in ein NuGet-Paket gepackt und auf einen NuGet-Server (privat oder öffentlich) hochgeladen werden.

2. Aktualisierung der Pakete:

   • Wenn Sie ein NuGet-Paket verwenden, können Sie die Bibliothek in allen Projekten, die darauf verweisen, aktualisieren, indem Sie einfach die Paketversion aktualisieren. Dies gewährleistet Konsistenz und verringert das Risiko von Versionsfehlern oder fehlenden Updates.

3. Vorteile:

   • Zentrale Verwaltung: NuGet-Pakete bieten eine zentrale Möglichkeit, Bibliotheksversionen und Abhängigkeiten zu verwalten.

   • Einfache Updates: Die Aktualisierung der Bibliothek über mehrere Projekte hinweg wird einfacher und zuverlässiger.

   • Integration: NuGet lässt sich in verschiedene Entwicklungstools und -umgebungen integrieren, wodurch die Verwaltung von Bibliotheksabhängigkeiten vereinfacht wird.

Initialer Testaufbau

Tim beginnt mit der Ausführung eines Unit-Tests, der aufgrund eines Fehlers in der DLL fehlschlägt. Er hebt die Bedeutung von Unit-Tests bei der Identifizierung von Problemen hervor, selbst wenn der Code außerhalb der Hauptlösung liegt. Der Code erwartete eine Eingabe mit 4 Buchstaben, stattdessen übergab Tim einen Vornamen mit 3 Buchstaben, der in der DLL-Datei abstürzt, auch wenn er nicht direkt in der Lösung enthalten ist.

Refactoring von Code zur Beseitigung von Fehlern

Um das Problem mit der Behandlung von Vornamen zu lösen, überarbeitet Tim den Code. Er erklärt, wie DRY auf die Entwicklung angewendet werden kann, indem er ein neues Klassenbibliotheksprojekt erstellt (23:50). Dieser Ansatz stellt sicher, dass Änderungen an mehreren Objekten einmal vorgenommen und effektiv getestet werden können, ohne dass sich die Korrekturen wiederholen.

Einheitstests hinzufügen

Tim führt eine neue Testklasse als EmployeeProcessorTest in das Klassenbibliotheksprojekt ein und richtet Unit-Tests mit XUnit ein. Er demonstriert, wie eine Testmethode zur Generierung von Mitarbeiter-IDs erstellt wird, und erörtert die Bedeutung von Mocking-Abhängigkeiten, anstatt sich auf tatsächliche Werte zu verlassen.

Schreiben einer Testmethode

Tim schreibt eine Unit-Test-Methode namens GenerateEmployeeID_ShouldCalculate. Er stellt eine Theorie mit Inline-Daten auf, um verschiedene Szenarien zu testen und sicherzustellen, dass die Methode die erwarteten Ergebnisse liefert. Er erklärt auch, wie man Assert.Equal verwendet, um die Ausgabe zu überprüfen.

public class EmployeeProcessorTest
{
   [Theory]
   [InlineData("Timothy", "Corey", "TimoCore")]
   public void GenerateEmployeeID_ShouldCalculate(string firstName, string lastName, string expectedStart)
   {
      // Arrange
      var processor = new EmployeeProcessor();

      // Act
      var actualStart = processor.GenerateEmployeeID(firstName, lastName).Substring(0, 8);

      // Assert
      Assert.Equal(expectedStart, actualStart);
   }
}

public class EmployeeProcessorTest
{
   [Theory]
   [InlineData("Timothy", "Corey", "TimoCore")]
   public void GenerateEmployeeID_ShouldCalculate(string firstName, string lastName, string expectedStart)
   {
      // Arrange
      var processor = new EmployeeProcessor();

      // Act
      var actualStart = processor.GenerateEmployeeID(firstName, lastName).Substring(0, 8);

      // Assert
      Assert.Equal(expectedStart, actualStart);
   }
}

Ausführung des Unit-Tests

Tim betont die Bedeutung des Mockings dynamischer Daten, wie z. B. Datums- und Zeitwerte, zur Kontrolle von Testbedingungen und -ergebnissen. Er erörtert die Herausforderung der Arbeit mit dynamischen Zeichenketten und wie man verschiedene Szenarien mit kontrollierten Werten testen kann. Er führt dann den Unittest aus, fügt jedoch zuvor zwei NuGet-Pakete hinzu, die zum Ausführen der Tests erforderlich sind: xunit.runner.console und xunit.runner.visualstudio.

Nachdem alle Tests für eine Inline-Datei erfolgreich durchgeführt wurden, wird die Ausgabe wie folgt angezeigt:

Jetzt um (31:30) hat Tim eine weitere Inline-Datenzeile hinzugefügt und den zweiten Parameter des Substrings in expectedStart.Length geändert:

public class EmployeeProcessorTest
{
   [Theory]
   [InlineData("Timothy", "Corey", "TimoCore")]
   [InlineData("Tim", "Corey", "TimCore")]
   public void GenerateEmployeeID_ShouldCalculate(string firstName, string lastName, string expectedStart)
   {
      var processor = new EmployeeProcessor();
      var actualStart = processor.GenerateEmployeeID(firstName, lastName).Substring(0, expectedStart.Length);
      Assert.Equal(expectedStart, actualStart);
   }
}

public class EmployeeProcessorTest
{
   [Theory]
   [InlineData("Timothy", "Corey", "TimoCore")]
   [InlineData("Tim", "Corey", "TimCore")]
   public void GenerateEmployeeID_ShouldCalculate(string firstName, string lastName, string expectedStart)
   {
      var processor = new EmployeeProcessor();
      var actualStart = processor.GenerateEmployeeID(firstName, lastName).Substring(0, expectedStart.Length);
      Assert.Equal(expectedStart, actualStart);
   }
}

Nach der erneuten Ausführung des Einheitstests bei (32:05) brach der Test bei der zweiten Theorie ab:

Verbesserung von Code mit privaten Methoden

Um DRY einzuhalten, refaktoriert Tim den Code weiter, indem er eine private Methode GetPartOfName in der aktuellen EmployeeProcessor Klasse unter der DRYDemoLibrary erstellt. Mit dieser Methode können Teile eines Namens extrahiert werden, was die Wiederverwendbarkeit und Lesbarkeit des Codes verbessert. Tim hat die folgenden Änderungen vorgenommen:

public string GenerateEmployeeID(string firstName, string lastName)
{
   string employeeID = $@"{GetPartOfName(firstName, 4)}{GetPartOfName(lastName, 4)}{DateTime.Now.Millisecond.ToString()}";
   return employeeID;
}

private string GetPartOfName(string name, int numberOfCharacters)
{
   string output = name;

   if (name.Length > numberOfCharacters)
   {
      output = name.Substring(0, numberOfCharacters);
   }

   return output;
}

public string GenerateEmployeeID(string firstName, string lastName)
{
   string employeeID = $@"{GetPartOfName(firstName, 4)}{GetPartOfName(lastName, 4)}{DateTime.Now.Millisecond.ToString()}";
   return employeeID;
}

private string GetPartOfName(string name, int numberOfCharacters)
{
   string output = name;

   if (name.Length > numberOfCharacters)
   {
      output = name.Substring(0, numberOfCharacters);
   }

   return output;
}

Aktualisierung von Unit-Tests

Tim aktualisiert die Unit-Tests, um Änderungen im Code zu berücksichtigen, wie z. B. die Änderung der erwarteten Länge von Teilstrings. Er erklärt, wie die Durchführung dieser Tests hilft, Probleme schnell zu erkennen und zu überprüfen, ob der Code den neuen Anforderungen entspricht. Tim fügt neue Theorien hinzu und führt dann die Unit-Tests aus, um zu überprüfen, ob die Ergebnisse den Erwartungen entsprechen:

Erstellen einer .NET Standard Bibliothek

Reduzierung von Wiederholungen in der Entwicklung

Tim Corey betont, dass Sie durch die Einführung einer .NET Standard-Bibliothek die Wiederholung von Code nicht nur in Ihrer Codebasis, sondern auch im Entwicklungsprozess minimieren. Anstatt Code in verschiedenen plattformspezifischen Projekten zu duplizieren, zentralisieren Sie ihn in einer einzigen Bibliothek, die in mehreren Umgebungen funktioniert.

Vorteile:

• Einheitliche Codebasis: Eine Codebasis für verschiedene Plattformen reduziert den Aufwand für die Wartung und Aktualisierung Ihres Codes.
• Vereinfachtes Testen: Mit einer .NET Standard-Bibliothek können Sie Unit-Tests einmal schreiben und sicherstellen, dass sie für alle unterstützten Plattformen gelten.

Testen und Debuggen: Tim stellt Unit-Tests als eine Möglichkeit vor, den Aufwand und die Wiederholungen weiter zu reduzieren. Automatisierte Tests überprüfen die Korrektheit Ihres Codes, ohne dass Sie jede Iteration der Anwendung manuell testen müssen.