C#

Json.NET（Newtonsoft.Json）では、XmlNodeConverter を利用することで、JSON と XML を簡単に相互変換できます。 変換の際には、要素・属性・テキスト・コメント・文字データ・処理命令・名前空間・XML宣言といった情報がすべて保持されるため、両形式の間でデータをやり取りしても構造や内容が失われません。 SerializeXmlNode：XMLからJSONへ変換する JsonConvert クラスには、JSON と XML を相互変換するためのヘルパーメソッドが2つ用意されています。 1つ目が SerializeXmlNode() です。このメソッドは

結合された（依存関係を持つ）オブジェクトを、疎結合な（独立した）オブジェクトへと変換しながら注入するプロセスは「依存性注入（Dependency Injection：DI）」と呼ばれます。DIはオブジェクト指向設計における重要なデザインパターンの一つであり、C#をはじめとする多くの言語でソフトウェアの柔軟性とテスト容易性を高めるために広く活用されています。 依存性注入の4つの種類 DIには主に以下の4つの実装手法があります。 コンストラクタインジェクション セッターインジェクション インターフェースベースのインジェクション サービスロケータインジェクション 1. コンストラクタインジェ

C#でファイルをコピーするには、System.IO名前空間に用意されているFile.Copyメソッドを使用します。このメソッドは引数の指定方法が異なる2つのオーバーロードを持っており、用途に応じて使い分けることができます。 File.Copyメソッドの2つのオーバーロード Copy(String, String) 既存のファイルを新しいパスへコピーします。コピー先に同じ名前のファイルが存在する場合はIOExceptionがスローされ、上書きはできません。 Copy(String, String, Boolean) 第3引数にbool値（overwrite）を指定できるバージョンです。trueを

FluentValidationとはFluentValidationは、.NET向けの強く型付けされたバリデーション（検証）ルールを構築するためのライブラリです。流暢なインターフェース（Fluent Interface）とラムダ式を活用して検証ルールを記述できるのが大きな特徴で、ドメインコードをすっきりと整理し、凝集度の高い設計を実現できます。また、検証ロジックを一箇所にまとめられるため、保守性も大幅に向上します。パッケージのインストールFluentValidationを使用するには、まず以下のNuGetパッケージをプロジェクトに追加します。<PackageReference Inclu

C#でモデルクラスのプロパティに対して検証ルールを定義するなら、定番ライブラリFluentValidationが便利です。本記事では、「生年月日（DateOfBirth）が今年より未来の日付であればエラーにする」というよくある要件を、RuleForメソッドとMust句を使って実装する手順を解説します。RuleForメソッドで検証ルールを定義する特定のプロパティに対して検証ルールを指定するには、RuleForメソッドを呼び出し、検証したいプロパティを示すラムダ式を渡します。RuleFor(p => p.DateOfBirth)上記の例では、PersonModelクラスのDateOfBirt

C#アプリケーションで入力値の文字数制限を検証したい場合、FluentValidationライブラリを使用すると、簡潔かつ宣言的にルールを記述できます。この記事では、文字列プロパティに対して最大長と最小長の検証を行うMaximumLengthおよびMinimumLengthバリデーターの使い方を、実際のコード例とともに解説します。 MaxLength（最大長）バリデーターとは MaximumLengthは、特定の文字列プロパティの長さが指定した値を超えないことを保証するバリデーターです。たとえば「名前は7文字以内」といったビジネスルールを簡単に表現できます。 文字列型（string）のプロ

IEnumerableとはIEnumerableは、IEnumeratorインターフェースを返す単一のメソッドGetEnumerator()を定義したインターフェースです。列挙（反復処理）が可能なすべての非ジェネリックコレクションの基底インターフェースとして機能します。IEnumerableを実装したコレクションに対しては読み取り専用のアクセスが可能となり、foreachステートメントを使って要素を順番に取り出すことができます。ListとはListクラスは、インデックスを使ってアクセスできるオブジェクトのリストを表します。System.Collections.Generic名前空間に属しており

C#でディレクトリ一覧を取得するには、Directory.GetDirectories メソッドを使用します。このメソッドは、指定したディレクトリ内で検索パターンに一致するサブディレクトリの名前（パスを含む）を返し、オプションでサブディレクトリも再帰的に検索できます。検索パターンとして使用する「*」は、その位置にある0文字以上の任意の文字列に一致します。また、SearchOption.TopDirectoryOnly を指定すると最上位のディレクトリのみを取得し、SearchOption.AllDirectories を指定するとすべてのトップレベルディレクトリとそのサブディレクトリを取得しま

同期（同期的）なC#のコードでは、例外は呼び出しスタックを遡って伝播し、最終的にその例外を処理できる適切なcatchブロックに到達します。しかし、非同期メソッドにおける例外処理は、これほど単純ではありません。C#の非同期メソッドは、戻り値として「void」「Task」「Task<T>」の3種類を持つことができます。このうち、戻り値がTaskまたはTask<T>である非同期メソッド内で例外が発生した場合、例外オブジェクトはAggregateExceptionにラップされ、Taskオブジェクトに格納されます。また、複数の例外がスローされた場合には、それらすべてがTaskオブ

C#でファイルやフォルダを操作する場合、System.IO名前空間に用意されたクラスとメソッドを活用すると効率的です。本記事では、指定したフォルダ内のファイルを再帰的に取得し、そのサイズを「KB」「MB」「GB」といった人間が読みやすい単位に変換して表示する方法を解説します。 ディレクトリとファイルの一覧を取得する サブディレクトリの一覧を取得するには、Directory.GetDirectoriesメソッドを使用します。このメソッドは、指定した検索パターンに一致するサブディレクトリの名前（パスを含む）を返し、オプションでさらに下位のサブディレクトリも検索できます。 ファイルの一覧を取得する

はじめに：usingディレクティブとusingステートメントC#には「using」に関連する機能が2種類あります。1つは名前空間をインポートしたり、名前空間や型にエイリアス（別名）を作成するためのusingディレクティブです。これらはファイルの先頭、すべての宣言よりも前に記述します。using System; using System.IO; using WinForms = global::System.Windows.Forms; using WinButton = WinForms::Button;もう1つが本記事のテーマであるusingステートメントです。こちらはリソース管理において非

Nullオブジェクトパターン（Null Object Pattern）は、nullチェックをできる限り排除し、クリーンで読みやすいコードを実現するためのデザインパターンです。このパターンを採用すると、呼び出し元は受け取ったオブジェクトが「null」なのか「実際の処理を持つオブジェクト」なのかを意識する必要がなくなります。 ただし、あらゆる場面にこのパターンを適用できるわけではありません。状況によっては、null参照を返してnullチェックを行う方が自然なケースも存在します。そのため、適材適所での使い分けが重要です。 Nullオブジェクトパターンとは？ Nullオブジェクトパターンでは、「何も

アンマネージリソース(アンマネージオブジェクト)を確実に解放する必要がある場面では、IDisposableデザインパターン(Disposeパターン)を採用するのが推奨されます。 IDisposableデザインパターンを実装する際は、アンマネージオブジェクトを直接的または間接的に扱うクラスに対してIDisposableインターフェースを実装し、同インターフェース内で宣言されているDisposeメソッドを定義します。実際の開発では、アンマネージオブジェクトを直接操作することはほとんどなく、それらを内部で扱うマネージクラス(ファイルハンドラ、データベース接続文字列、HTTPストリームなど)を経由し

C#では、Directory.GetFilesメソッドを使用することで、指定したディレクトリ内のファイルを簡単に取得できます。Directory.GetFilesメソッドとはDirectory.GetFilesは、指定された検索パターンに一致するすべてのファイル名（フルパスを含む）を返すメソッドです。オプションを指定することで、サブディレクトリまで含めた検索も可能になります。検索パターンの「*（アスタリスク）」は、その位置にある0文字以上の任意の文字列に一致します。SearchOption.TopDirectoryOnly：最上位のディレクトリのみを検索します。SearchOption.All

C#における sealed（封印）キーワードは、そのクラスが継承できないことを意味します。一方、コンストラクタを private で宣言すると、クラスの外部からインスタンスを生成できなくなります。この2つは似ているようで役割が異なり、シングルトンパターンを実装するうえでは両方が重要になります。 privateコンストラクタだけでは不十分な理由 一見すると、コンストラクタをprivateにすれば誰もインスタンスを生成できず、シングルトンは完成したように思えます。しかし実際には、privateコンストラクタを持つ基底クラスであっても、そこから派生クラスを作成し、派生クラス側でpublicコンス

派生型は、その基底型と完全に置き換え可能でなければなりません。これがリスコフの置換原則（Liskov Substitution Principle：LSP）の核心です。LSPはSOLID原則の「L」に相当し、オブジェクト指向における継承の正しい使い方を定める重要な指針となっています。 リスコフの置換原則の定義 リスコフの置換原則とは、「子クラス（派生クラス）を、あたかも親クラス（基底クラス）であるかのように扱えるべきである」という原則です。本質的には、すべての派生クラスが親クラスの機能を保持し、親クラスが提供する機能を勝手に置き換えてしまってはならない、ということを意味します。 この原則を守る

FacadeパターンとはFacade（ファサード）パターンは、GoFデザインパターンのひとつで、複雑なサブシステムの上にシンプルな「窓口」を設ける構造を指します。名前の由来は建築用語の「ファサード（建物の正面外観）」で、複雑な内部構造を隠蔽し、利用者には簡潔なインターフェースだけを見せることを目的としています。つまりFacadeパターンとは、「より複雑な構造の上に、よりシンプルな構造を重ねる」ためのデザインパターンなのです。登場する要素（Participants）Subsystem（サブシステム）実際に機能を実装しているクラスやオブジェクトの集まりです。それぞれ独立して動作しますが、Facad

「クライアントは、自分が利用しないインターフェースに依存することを強制されるべきではない」——これが、SOLID設計原則の一つであるインターフェース分離の原則（Interface Segregation Principle：ISP）の核心です。 この原則は、クライアントに対して、実際には使用しないメンバーを持つインターフェースの実装を強制してはならないことを意味します。巨大で肥大化した単一のインターフェース（ファットインターフェース）を作るのではなく、メソッド群を目的ごとにグループ化し、それぞれの小さなインターフェースが一つのサブモジュールに対応する形に分割するのが望ましいとされています。 イ

プロキシパターンとはプロキシ（Proxy）パターンは、GoFデザインパターンのひとつで、別のオブジェクトへのアクセスを制御するための「代理（サロゲート）」または「プレースホルダー」となるオブジェクトを提供します。プロキシオブジェクトは、元となるオブジェクトとまったく同じ方法で利用できるため、クライアント側は本物のオブジェクトとプロキシの違いを意識することなくコードを書けます。パターンの構成要素（参加者）Subject（対象）：RealSubject と Proxy の両方に共通するインターフェースを定義します。これにより、RealSubject が期待されるあらゆる場面で Proxy を代わり

依存性逆転の原則（Dependency Inversion Principle：DIP）は、SOLID原則の一つであり、オブジェクト指向設計において非常に重要な指針です。この原則は次のように定義されています。 上位レベルのモジュールは、下位レベルのモジュールに依存してはならない。両者とも「抽象」に依存すべきである。 抽象は詳細に依存してはならない。「詳細」が抽象に依存すべきである。 この原則の主な目的は、コードモジュール間の依存関係を減らし、システム全体の柔軟性・保守性・拡張性を高めることです。ここでは、C#を使った具体的な実装例を見ていきましょう。 実装例 依存性逆転を適用する前のコー