開発をしていると、こんな瞬間がありませんか。
- if/else が増えすぎて読みにくい
- クラス同士の依存が強くてテストしづらい
- ちょっと機能を追加したいだけなのに既存コードを触りたくない
- 外部 API の仕様変更の影響範囲が広すぎる
- 設定やログなど「アプリ全体で1つだけあればいいもの」が散らばっている
私自身、実務で何度もこうした悩みにぶつかってきました。
そしてそのたびに助けられたのが デザインパターン です。
この記事では、現場で特に「効いた」と感じたパターンを、
“どう使うのか” が一目で分かる C# 実装例つきで紹介します。
1. Strategy（ストラテジー）
if/else 地獄を抜け出すためのパターン
料金計算、認証方式、フィルタリングなど、
アルゴリズムを切り替えたい場面は実務で本当に多いです。
❌ Strategy を使わないとどうなるか
public decimal CalculatePrice(decimal price, string discountType)
{
if (discountType == "None")
return price;
if (discountType == "Seasonal")
return price * 0.9m;
if (discountType == "Member")
return price * 0.8m;
throw new ArgumentException("Unknown discount type");
}
- 条件分岐が増えるたびにメソッドが肥大化
- テストしづらい
- 新しい割引ロジック追加時に既存コードを触る必要がある
⭕ Strategy を使うとこうなる
アルゴリズムをクラスとして分離
public interface IDiscountStrategy
{
decimal Apply(decimal price);
}
public class NoDiscount : IDiscountStrategy
{
public decimal Apply(decimal price) => price;
}
public class SeasonalDiscount : IDiscountStrategy
{
public decimal Apply(decimal price) => price * 0.9m;
}
public class MemberDiscount : IDiscountStrategy
{
public decimal Apply(decimal price) => price * 0.8m;
}
実際の使い方
IDiscountStrategy strategy = new MemberDiscount();
var calculator = new PriceCalculator(strategy);
var result = calculator.Calculate(1000m);
Console.WriteLine(result); // 800
🎯 Strategy のメリット
- 条件分岐が消えて読みやすい
- 新しいロジック追加時に既存コードを触らなくていい
- 各 Strategy を単体でテストできる
- DI と相性が良い
2. Decorator（デコレーター）
「既存の処理にちょい足ししたい」を綺麗に実現
ログ追加、キャッシュ追加、認可チェックなど、
既存の処理に機能を後付けしたい場面は本当に多いです。
❌ よくある「ちょい足し地獄」
public class UserService
{
public void Save(User user)
{
Console.WriteLine("Start log");
// 保存処理
Console.WriteLine("End log");
}
}
⭕ Decorator を使うとこうなる
元の処理はシンプルなまま
public interface IUserService
{
void Save(User user);
}
public class UserService : IUserService
{
public void Save(User user)
{
Console.WriteLine("Saving user...");
}
}
デコレーターで「ちょい足し」
public class LoggingUserService : IUserService
{
private readonly IUserService _inner;
public LoggingUserService(IUserService inner)
{
_inner = inner;
}
public void Save(User user)
{
Console.WriteLine("Start log");
_inner.Save(user);
Console.WriteLine("End log");
}
}
実際に使ってみる
IUserService service = new UserService();
service = new LoggingUserService(service);
service.Save(new User("Taro"));
🎯 Decorator のメリット
- 元のクラスを一切変更せずに機能追加できる
- ログ・キャッシュ・認可などを組み合わせて使える
- 継承より柔軟
3. Adapter（アダプター）
外部 API やレガシーコードとの“つなぎ込み”に必須
実務では「使いたいけどインターフェースが合わない」問題が頻発します。
❌ Adapter がないとどうなる？
public class SlackApi
{
public void PostMessage(string text) { ... }
}
public class NotificationService
{
public void Notify(string message)
{
var slack = new SlackApi();
slack.PostMessage(message);
}
}
⭕ Adapter を使うと柔軟になる
アプリ側のインターフェース
public interface INotification
{
void Send(string message);
}
Slack 用のアダプター
public class SlackAdapter : INotification
{
private readonly SlackApi _slack;
public SlackAdapter(SlackApi slack)
{
_slack = slack;
}
public void Send(string message)
{
_slack.PostMessage(message);
}
}
アプリ側からの使い方
var slackApi = new SlackApi();
INotification notifier = new SlackAdapter(slackApi);
notifier.Send("Hello from Adapter!");
🎯 Adapter のメリット
- 外部 API の仕様変更に強い
- テストしやすい（モック差し替え可能）
- レガシーコードの置き換えがスムーズ
4. Singleton（シングルトン）
「アプリ全体で1つだけあればいいもの」を安全に共有する
❌ シングルトンを使わないとどうなる？
public class AppConfig
{
public string ConnectionString { get; }
public AppConfig()
{
ConnectionString = "Server=localhost;Database=Sample;";
}
}
⭕ シングルトンを使うとこうなる
public sealed class AppConfig
{
private static readonly Lazy<AppConfig> _instance =
new Lazy<AppConfig>(() => new AppConfig());
public static AppConfig Instance => _instance.Value;
public string ConnectionString { get; }
private AppConfig()
{
ConnectionString = "Server=localhost;Database=Sample;";
}
}
インスタンスの取得方法
var config = AppConfig.Instance;
Console.WriteLine(config.ConnectionString);
🎯 Singleton のメリット
- インスタンスが1つだけなので状態が安定
- 設定やログなど「アプリ全体で共有したいもの」を安全に扱える
- Lazy による遅延初期化で無駄な処理を避けられる
まとめ：パターンは“綺麗に書くための道具”ではなく“問題を解決するための道具”
今回紹介したパターンは、どれも実務で本当に役立つものばかりです。
- Strategy：条件分岐をなくして拡張しやすく
- Decorator：既存コードを汚さずに機能追加
- Adapter：外部 API やレガシーとの橋渡し
- Singleton：アプリ全体で共有したいものを安全に扱う
デザインパターンは「覚えるもの」ではなく、
困ったときに思い出す引き出しのような存在だと思っています。