DRY原則をマスターする：C#でデザインパターンを適用してコードをクリーンにする

ステップと例:

1.初期コード：従業員IDを生成するためのロジックは、ボタンのクリックイベントハンドラに直接ありました。

2.リファクタリングされたコード: Timは、より柔軟にすることでメソッドを改善します。 特定のUI要素に依存する代わりに、このメソッドはパラメーターとして firstName と lastName を受け取り、生成されたIDを返します。 この変更により、このメソッドをさまざまなコンテキストやUI要素で使用できるようになります：

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

Timは次に、このメソッドがクリックイベントからどのように呼び出されるかを示します：

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

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

また、この方法は、コードを繰り返すことなく、複数の従業員レコードを含むCSVファイルの処理など、アプリケーションの他の部分でも使用できるようになったことも指摘している。

ステップと例:

1.クラスライブラリの作成:

• (9:47)で、Timは.NET Frameworkで新しいクラスライブラリプロジェクトを作成し、DRYDemoLibraryと名付けています。

• このライブラリ内で、彼はパブリッククラス EmployeeProcessor を定義し、GenerateEmployeeID メソッドをこのクラスに移動します:

    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.プロジェクトでクラスライブラリを使用する:

• WinFormsプロジェクト（13:18）とWPFプロジェクト（14:00）では、TimはDRYDemoLibraryクラス・ライブラリへの参照を追加しています。

• 次に、古いコードをクラスライブラリの GenerateEmployeeID メソッドの呼び出しで置き換えます:

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

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

• このアプローチでは、メソッドが一箇所で管理されるため、冗長性がなくなります。 Timは、コードを繰り返すことなく、同じクラスライブラリを異なるUIフレームワーク（WinFormsとWPF）で使用できることを示します。

3.利点:

• 一貫性：ロジックをクラスライブラリに一元化することで、Timはロジックへの変更（バグ修正など）がすべてのプロジェクトで一律に適用されるようにします。

• メンテナンスの軽減:メソッドの変更はクラスライブラリで行うだけでよいため、不整合を回避し、メンテナンスのオーバーヘッドを削減します。

ステップと例:

1.新しいソリューションとプロジェクトの作成:。

• (17:29)のTimは、Windowsサービスやコンソールアプリのような異なるタイプのプロジェクトでDRYDemoLibraryを使用する必要があるかもしれないシナリオをシミュレートしながら、コンソールアプリケーション用の新しいソリューションを作成することから始めます。

• 彼は新しいプロジェクトをConsoleUIと名付け、基本的なコンソール・アプリケーションのセットアップ方法を示している。

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

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

2.クラスライブラリに参照を追加する:。

• Timは、新しいプロジェクトにDRYDemoLibrary DLLへの参照を追加する方法を説明します。 これには、クラス・ライブラリ・プロジェクトのbinフォルダ内のDLLファイルを参照し、コンソール・アプリケーションに追加することが含まれます。

    using DRYDemoLibrary;

    using DRYDemoLibrary;

• リファレンスが追加されると、Tim (19:24) はライブラリから EmployeeProcessor クラスを使用して、ユーザー入力に基づいて従業員 ID を生成する。

    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.コンソールアプリケーションの実行:

• Timは、コンソール・アプリケーションを実行して、ライブラリを使用して従業員IDが正常に生成されることを示します。 これにより、クラスライブラリの同じコードを異なるプロジェクトで再利用できることが確認されます。

  

4.DLLの更新:。

• Timは、DLLが変更された場合、それを参照するプロジェクトでそれを更新できることに簡単に触れています。 このビデオでは詳しく取り上げていないが、NuGet パッケージの使用は、複数のプロジェクトにまたがる DLL の管理と更新に推奨されるアプローチである、と彼は指摘する。

主なポイント:

1.NuGetパッケージの作成:。

• DLLファイルを手動で管理する代わりに、Tim氏はクラスライブラリのNuGetパッケージを作成することを提案しています。 これには、DLLをNuGetパッケージにパッケージ化し、NuGetサーバー（プライベートまたはパブリック）にアップロードすることが含まれます。

2.パッケージの更新:。

• NuGetパッケージを使用することで、パッケージのバージョンを更新するだけで、ライブラリを参照するすべてのプロジェクトでライブラリを更新できます。 これにより、一貫性が確保され、バージョンの不一致や更新漏れのリスクが軽減されます。

3.メリット:

• 一元管理: NuGetパッケージは、ライブラリのバージョンと依存関係を一元管理する方法を提供します。

• アップデートの容易さ：複数のプロジェクトにまたがるライブラリのアップデートが容易になり、信頼性が高まります。

• 統合: NuGetはさまざまな開発ツールや環境と統合し、ライブラリの依存関係を管理するプロセスを合理化します。

初期テストのセットアップ

Timは、DLLのバグが原因で現在失敗しているユニットテストを実行することから始めます。 彼は、コードが主要なソリューションの外にある場合でも、問題を特定するためのユニットテストの重要性を強調しています。 コードは4文字の入力を想定していましたが、代わりにTimは3文字のファーストネームを渡し、それがソリューションに直接含まれていなくてもDLLファイルでクラッシュしました。

バグに対処するためのコードのリファクタリング

ファーストネームの取り扱いに関する問題に対処するため、ティムはコードをリファクタリングします。 新しいクラス・ライブラリ・プロジェクトを作成することで、DRYが開発にどのように適用できるかを説明する（23:50）。 このアプローチにより、複数のオブジェクトに対する変更を一度だけ行い、修正を繰り返すことなく効果的にテストすることができます。

ユニットテストの追加

Tim は、クラス・ライブラリ・プロジェクトに EmployeeProcessorTest という新しいテスト・クラスを導入し、XUnit を使用してユニット・テストを設定します。 従業員IDを生成するテスト・メソッドの作成方法を示し、実際の値に依存するのではなく、依存関係をモックすることの重要性について議論する。

テストメソッドの記述

Tim は、GenerateEmployeeID_ShouldCalculate というユニットテストメソッドを書いています。 彼は、異なるシナリオをテストするためにインラインデータで理論を設定し、メソッドが期待される結果を返すようにします。 また、出力を検証するためにAssert.Equalを使用する方法についても説明しています。

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

ユニットテストの実行

Timは、テスト条件と結果を制御するために、日付時刻値のような動的データをモックすることの重要性を強調しています。 動的な文字列を扱うことの難しさや、制御された値を使用してさまざまなシナリオをテストする方法について説明します。 次に彼はユニットテストを実行しますが、その前にテストを実行するために必要な二つのNuGetパッケージ xunit.runner.console と xunit.runner.visualstudio を追加します。

1つのインラインデータに対してすべてのテストを正常に実行した後、出力は次のようになります：

現在 (31:30) で、Timはもう一つのインラインデータを追加し、サブストリングの第二引数を expectedStart.Length に変更しました:

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

(32:05)でユニットテストを再度実行した後、2番目の理論でテストが壊れました：

プライベート メソッドでコードを改善する

DRY原則に従うため、Timはコードをさらにリファクタリングし、DRYDemoLibraryの実際の EmployeeProcessor クラス内にプライベートメソッド GetPartOfName を作成します。 このメソッドは、名前の一部を抽出し、コードの再利用性と可読性を向上させます。 ティムは以下の変更を行いました：

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

ユニットテストの更新

Timは、部分文字列の予想される長さを修正するなど、コードの変更を反映するためにユニットテストを更新します。 また、これらのテストを実行することで、問題を迅速に特定し、コードが新しい要件を満たしていることを検証することができることを説明しています。 ティムは新しい理論を追加し、ユニットテストを実行して、出力が期待通りかどうかを検証します：

.NET標準ライブラリを作成する

開発における繰り返しを減らす

ティム・コリーは、.NET Standardライブラリを採用することで、コードベースだけでなく、開発プロセスにおいてもコードの繰り返しを最小限に抑えることができると強調しています。 異なるプラットフォーム固有のプロジェクトでコードが重複する代わりに、複数の環境で動作する単一のライブラリにコードを集中させます。

メリット:

• 統一されたコードベース：さまざまなプラットフォーム用の1つのコードベースは、コードの保守と更新に必要な労力を削減します。
• 簡素化されたテスト：.NET Standardライブラリを使えば、単体テストを一度書くだけで、サポートされているすべてのプラットフォームに適用できるようになります。

テストとデバッグ：Timは、労力と繰り返しをさらに減らす方法として、ユニットテストを紹介します。 自動テストは、アプリケーションの各反復を手動でテストする必要なく、コードの正しさを検証します。