SOLID原則
ソリッド(SOLID)原則について、C#を用いて解説してください。
1. 単一責任の原則 (SRP)
項目ごとに、質問します。
まず、「1. 単一責任の原則 (SRP)」について、より詳しく解説してください。
単一責任の原則（Single Responsibility Principle）について、より詳しく解説させていただきます。
// 悪い例：複数の責任を持つクラス
public class UserService
{
private readonly DbContext _context;
private readonly SmtpClient _emailClient;
public UserService(DbContext context, SmtpClient emailClient)
{
_context = context;
_emailClient = emailClient;
}
public void RegisterUser(User user)
{
// ユーザー情報の検証
if (string.IsNullOrEmpty(user.Email))
throw new ValidationException("Email is required");
if (string.IsNullOrEmpty(user.Password))
throw new ValidationException("Password is required");
if (user.Password.Length < 8)
throw new ValidationException("Password must be at least 8 characters");
// パスワードのハッシュ化
user.Password = HashPassword(user.Password);
// データベースへの保存
_context.Users.Add(user);
_context.SaveChanges();
// ウェルカムメールの送信
var message = new MailMessage
{
To = { user.Email },
Subject = "Welcome to our service!",
Body = $"Dear {user.Name}, welcome to our service..."
};
_emailClient.Send(message);
}
private string HashPassword(string password)
{
// パスワードハッシュ化ロジック
return BCrypt.HashPassword(password);
}
}
// 良い例：責任を適切に分割したクラス群
public class UserValidator
{
public void ValidateUser(User user)
{
var errors = new List<string>();
if (string.IsNullOrEmpty(user.Email))
errors.Add("Email is required");
if (string.IsNullOrEmpty(user.Password))
errors.Add("Password is required");
if (user.Password.Length < 8)
errors.Add("Password must be at least 8 characters");
if (errors.Any())
throw new ValidationException(string.Join(", ", errors));
}
}
public class PasswordHasher
{
public string HashPassword(string password)
{
return BCrypt.HashPassword(password);
}
}
public class UserRepository
{
private readonly DbContext _context;
public UserRepository(DbContext context)
{
_context = context;
}
public void SaveUser(User user)
{
_context.Users.Add(user);
_context.SaveChanges();
}
}
public class EmailService
{
private readonly SmtpClient _emailClient;
public EmailService(SmtpClient emailClient)
{
_emailClient = emailClient;
}
public void SendWelcomeEmail(User user)
{
var message = new MailMessage
{
To = { user.Email },
Subject = "Welcome to our service!",
Body = $"Dear {user.Name}, welcome to our service..."
};
_emailClient.Send(message);
}
}
// 責任を分割したクラスを組み合わせて使用
public class UserRegistrationService
{
private readonly UserValidator _validator;
private readonly PasswordHasher _passwordHasher;
private readonly UserRepository _userRepository;
private readonly EmailService _emailService;
public UserRegistrationService(
UserValidator validator,
PasswordHasher passwordHasher,
UserRepository userRepository,
EmailService emailService)
{
_validator = validator;
_passwordHasher = passwordHasher;
_userRepository = userRepository;
_emailService = emailService;
}
public void RegisterUser(User user)
{
// 各責任を持つクラスを順番に呼び出す
_validator.ValidateUser(user);
user.Password = _passwordHasher.HashPassword(user.Password);
_userRepository.SaveUser(user);
_emailService.SendWelcomeEmail(user);
}
}
単一責任の原則について、重要なポイントを解説します：
- 原則の本質
- クラスが変更される理由は1つだけであるべき
- 「責任」とは「変更の理由」と言い換えることができます
- 1つのクラスは1つの関係者（アクター）にのみ対して責任を持つべき
- メリット
- コードの保守性が向上する
- テストが容易になる
- 変更の影響範囲が限定される
- コードの再利用性が高まる
- バグの混入リスクが低下する
- 実装例の解説
悪い例（
UserService）の問題点：
- バリデーション、パスワード処理、データ保存、メール送信と複数の責任を持っている
- 1つの機能を変更する際に、他の機能に影響を与えるリスクがある
- テストが複雑になる（全ての機能のモックが必要）
良い例の特徴：
UserValidator: バリデーションのみを担当PasswordHasher: パスワード関連の処理のみを担当UserRepository: データベース操作のみを担当EmailService: メール送信のみを担当UserRegistrationService: 各サービスの調整のみを担当
- 判断のポイント 以下の質問で責任が適切に分割されているか判断できます：
- このクラスが変更される理由は複数あるか？
- クラスの説明を一文で表現できるか？
- クラス名に “and” や “or” が含まれていないか？
- メソッドが共通の目的を持っているか？
- 注意点
- 責任の分割しすぎは逆に複雑性を増加させる可能性がある
- コンテキストに応じて適切な粒度を判断する
- 将来の変更可能性を考慮して設計する
単一責任の原則を適用する際の実践的なアドバイス：
- まずは大きめの責任で設計を始める
- コードの変更理由が複数出てきたら分割を検討する
- チームで責任の範囲について合意を形成する
- 定期的にコードレビューで責任の範囲を見直す
具体的な質問や、特定のケースについての相談がありましたら、お気軽にお申し付けください。
2. 開放/閉鎖の原則 (OCP)
次に「2. 開放/閉鎖の原則 (OCP)」について、より詳しく解説してください。
開放/閉鎖の原則（Open/Closed Principle）について、より詳細に解説させていただきます。
// 悪い例：新しい支払い方法を追加するたびにクラスを修正する必要がある
public class PaymentProcessor
{
public void ProcessPayment(string paymentMethod, decimal amount)
{
switch (paymentMethod)
{
case "CreditCard":
ProcessCreditCardPayment(amount);
break;
case "PayPal":
ProcessPayPalPayment(amount);
break;
case "BankTransfer":
ProcessBankTransferPayment(amount);
break;
// 新しい支払い方法を追加するたびにここを修正する必要がある
default:
throw new ArgumentException("Unknown payment method");
}
}
private void ProcessCreditCardPayment(decimal amount)
{
// クレジットカード決済の処理
}
private void ProcessPayPalPayment(decimal amount)
{
// PayPal決済の処理
}
private void ProcessBankTransferPayment(decimal amount)
{
// 銀行振込の処理
}
}
// 良い例：新しい支払い方法の追加が容易
public interface IPaymentMethod
{
void ProcessPayment(decimal amount);
bool ValidatePayment();
PaymentStatus GetPaymentStatus();
}
public class CreditCardPayment : IPaymentMethod
{
private readonly string _cardNumber;
private readonly string _expiryDate;
private readonly string _cvv;
public CreditCardPayment(string cardNumber, string expiryDate, string cvv)
{
_cardNumber = cardNumber;
_expiryDate = expiryDate;
_cvv = cvv;
}
public void ProcessPayment(decimal amount)
{
// クレジットカード決済の具体的な処理
Console.WriteLine($"Processing credit card payment of {amount:C}");
}
public bool ValidatePayment()
{
// クレジットカードの検証ロジック
return true;
}
public PaymentStatus GetPaymentStatus()
{
// 支払状況の確認
return PaymentStatus.Completed;
}
}
public class PayPalPayment : IPaymentMethod
{
private readonly string _email;
private readonly string _password;
public PayPalPayment(string email, string password)
{
_email = email;
_password = password;
}
public void ProcessPayment(decimal amount)
{
// PayPal決済の具体的な処理
Console.WriteLine($"Processing PayPal payment of {amount:C}");
}
public bool ValidatePayment()
{
// PayPalアカウントの検証ロジック
return true;
}
public PaymentStatus GetPaymentStatus()
{
// 支払状況の確認
return PaymentStatus.Completed;
}
}
// 新しい支払い方法を追加する場合は、インターフェースを実装するだけ
public class CryptoCurrencyPayment : IPaymentMethod
{
private readonly string _walletAddress;
public CryptoCurrencyPayment(string walletAddress)
{
_walletAddress = walletAddress;
}
public void ProcessPayment(decimal amount)
{
// 暗号通貨決済の具体的な処理
Console.WriteLine($"Processing crypto payment of {amount:C}");
}
public bool ValidatePayment()
{
// ウォレットアドレスの検証ロジック
return true;
}
public PaymentStatus GetPaymentStatus()
{
// 支払状況の確認
return PaymentStatus.Pending;
}
}
// 支払い処理を行うクラス
public class ModernPaymentProcessor
{
public void ProcessPayment(IPaymentMethod paymentMethod, decimal amount)
{
if (paymentMethod.ValidatePayment())
{
paymentMethod.ProcessPayment(amount);
var status = paymentMethod.GetPaymentStatus();
// 状態に応じた処理
}
}
}
// 使用例
public class OrderService
{
private readonly ModernPaymentProcessor _paymentProcessor;
public OrderService(ModernPaymentProcessor paymentProcessor)
{
_paymentProcessor = paymentProcessor;
}
public void PlaceOrder(Order order, IPaymentMethod paymentMethod)
{
// 注文処理
_paymentProcessor.ProcessPayment(paymentMethod, order.TotalAmount);
}
}
開放/閉鎖の原則について、重要なポイントを解説します：
- 原則の本質
- ソフトウェアの構成要素（クラス、モジュール、関数など）は拡張に対して開いていて、修正に対して閉じているべき
- 新しい機能を追加する際に、既存のコードを変更する必要がないようにする
- 抽象化（インターフェースや抽象クラス）を活用して実現する
- メリット
- コードの保守性が向上する
- 既存の機能への影響を最小限に抑えられる
- テストが容易になる
- 新機能の追加が安全になる
- コードの再利用性が高まる
- 実装例の解説
悪い例（
PaymentProcessor）の問題点：
- 新しい支払い方法を追加するたびに、既存のクラスを修正する必要がある
- switch文が長くなり、保守が困難になる
- 単一責任の原則にも違反している
良い例の特徴：
IPaymentMethodインターフェースを定義- 各支払い方法は個別のクラスとして実装
- 新しい支払い方法の追加が容易（既存コードの変更不要）
ModernPaymentProcessorは具象クラスに依存せず、インターフェースに依存
- 実装のパターン OCPを実現する一般的なパターン：
- Strategy パターン（今回の例で使用）
- Template Method パターン
- Factory パターン
- Decorator パターン
- 注意点
- 過度な抽象化は避ける
- 将来の変更を適切に予測する必要がある
- インターフェースの設計は慎重に行う
- 拡張ポイントを適切に選択する
- 適用のタイミング
- 同じような変更が繰り返し発生する場合
- 機能の追加が頻繁に行われる場合
- 複数のバリエーションが存在する場合
- プラグイン機構が必要な場合
実践的なアドバイス：
- まずはシンプルに始める
- 実際に変更が必要になったときにリファクタリングする
- 抽象化は必要最小限に留める
- チームで設計方針を共有する
具体的な質問や、特定のケースについての相談がありましたら、お気軽にお申し付けください。
3. リスコフの置換原則 (LSP)
次に「3. リスコフの置換原則 (LSP)」について、より詳しく解説してください。
リスコフの置換原則（Liskov Substitution Principle）について、より詳細に解説させていただきます。
// 悪い例：LSPに違反するケース
public class Bird
{
public virtual void Fly()
{
Console.WriteLine("Flying high in the sky!");
}
}
public class Penguin : Bird
{
public override void Fly()
{
// ペンギンは飛べないので、例外をスローする
throw new NotSupportedException("Penguins can't fly!");
}
}
// 上記のコードは以下のような問題を引き起こす
public class BirdHandler
{
public void MakeBirdFly(Bird bird)
{
bird.Fly(); // ペンギンの場合、例外が発生する
}
}
// 良い例：LSPに準拠した設計
public abstract class Animal
{
public abstract void Move();
}
public abstract class FlyingCreature : Animal
{
public virtual void Fly()
{
Console.WriteLine("Flying in the sky!");
}
public override void Move()
{
Fly();
}
}
public abstract class WalkingCreature : Animal
{
public virtual void Walk()
{
Console.WriteLine("Walking on the ground!");
}
public override void Move()
{
Walk();
}
}
public class Eagle : FlyingCreature
{
public override void Fly()
{
Console.WriteLine("Soaring high in the sky!");
}
}
public class Penguin : WalkingCreature
{
public override void Walk()
{
Console.WriteLine("Waddling along!");
}
}
// より実践的な例：Rectangle-Square問題
// 悪い例
public class Rectangle
{
public virtual int Width { get; set; }
public virtual int Height { get; set; }
public virtual int CalculateArea()
{
return Width * Height;
}
}
public class Square : Rectangle
{
private int _size;
public override int Width
{
get { return _size; }
set { _size = value; }
}
public override int Height
{
get { return _size; }
set { _size = value; }
}
}
// 良い例：形状を抽象化
public interface IShape
{
int CalculateArea();
}
public class Rectangle : IShape
{
public int Width { get; set; }
public int Height { get; set; }
public int CalculateArea()
{
return Width * Height;
}
}
public class Square : IShape
{
public int Size { get; set; }
public int CalculateArea()
{
return Size * Size;
}
}
// 実践的な例：データアクセス
public interface IRepository<T>
{
IEnumerable<T> GetAll();
T GetById(int id);
void Add(T entity);
void Update(T entity);
void Delete(int id);
}
public class ReadOnlyRepository<T> : IRepository<T>
{
public IEnumerable<T> GetAll()
{
// 読み取り実装
throw new NotImplementedException();
}
public T GetById(int id)
{
// 読み取り実装
throw new NotImplementedException();
}
// これらのメソッドは LSP 違反
public void Add(T entity)
{
throw new NotSupportedException("Read-only repository");
}
public void Update(T entity)
{
throw new NotSupportedException("Read-only repository");
}
public void Delete(int id)
{
throw new NotSupportedException("Read-only repository");
}
}
// 良い例：インターフェースを適切に分割
public interface IReadOnlyRepository<T>
{
IEnumerable<T> GetAll();
T GetById(int id);
}
public interface IWritableRepository<T> : IReadOnlyRepository<T>
{
void Add(T entity);
void Update(T entity);
void Delete(int id);
}
public class Repository<T> : IWritableRepository<T>
{
public IEnumerable<T> GetAll()
{
// 実装
throw new NotImplementedException();
}
public T GetById(int id)
{
// 実装
throw new NotImplementedException();
}
public void Add(T entity)
{
// 実装
throw new NotImplementedException();
}
public void Update(T entity)
{
// 実装
throw new NotImplementedException();
}
public void Delete(int id)
{
// 実装
throw new NotImplementedException();
}
}
public class ReadOnlyRepository<T> : IReadOnlyRepository<T>
{
public IEnumerable<T> GetAll()
{
// 実装
throw new NotImplementedException();
}
public T GetById(int id)
{
// 実装
throw new NotImplementedException();
}
}
リスコフの置換原則について、重要なポイントを解説します：
- 原則の本質
- 基底クラス型の変数に派生クラスのオブジェクトを代入して使用しても、プログラムが正しく動作すべき
- 派生クラスは基底クラスの契約（振る舞い）を守る必要がある
- 派生クラスは基底クラスの事前条件を強めてはならず、事後条件を弱めてはならない
- LSP違反の典型的な兆候
- 派生クラスで例外をスローする
- 派生クラスで機能を無効化する
- 継承関係に is-a 関係が成り立たない
- 型チェックやダウンキャストが必要になる
- メリット
- コードの再利用性が向上する
- ポリモーフィズムを安全に使用できる
- テストが容易になる
- コードの保守性が向上する
- 実装例の解説
悪い例の問題点：
BirdとPenguinの例：飛べない鳥に対してFlyメソッドを強制しているRectangleとSquareの例：正方形に対して幅と高さを別々に設定できてしまうReadOnlyRepositoryの例：書き込み操作で例外をスローしている
良い例の特徴：
- 適切な抽象化レベルを選択している
- インターフェースを適切に分割している
- 継承関係が自然である
- 派生クラスが基底クラスの契約を守っている
- 実践的なガイドライン
- 継承を使用する前に、本当に is-a 関係かを確認する
- インターフェースを小さく保つ
- 基底クラスの振る舞いを文書化する
- 契約プログラミングの原則を考慮する
- 一般的な解決パターン
- インターフェース分離
- コンポジション（継承の代わりに）
- テンプレートメソッドパターン
- Null Objectパターン
実装時の注意点：
- 継承よりもコンポジションを優先する
- 抽象クラスやインターフェースの設計を慎重に行う
- 単体テストで置換可能性を確認する
- ビジネスルールを考慮した設計を行う
具体的な質問や、特定のケースについての相談がありましたら、お気軽にお申し付けください。
4. インターフェース分離の原則 (ISP)
次に「4. インターフェース分離の原則 (ISP)」について、より詳しく解説してください。
インターフェース分離の原則（Interface Segregation Principle）について、より詳細に解説させていただきます。
// 悪い例：大きすぎるインターフェース
public interface IWorkStation
{
void Print(Document document);
void Scan(Document document);
void Fax(Document document);
void Email(Document document);
void Copy(Document document);
void PrintDuplex(Document document);
void StatuePrinter();
void CheckInk();
void CheckPaper();
}
// 問題点：基本的なプリンターはFaxやEmailの機能を持っていないのに
// 実装を強制される
public class BasicPrinter : IWorkStation
{
public void Print(Document document)
{
// 実装
}
public void Scan(Document document)
{
throw new NotSupportedException();
}
public void Fax(Document document)
{
throw new NotSupportedException();
}
public void Email(Document document)
{
throw new NotSupportedException();
}
// 他のメソッドも同様...
}
// 良い例：機能ごとに分離されたインターフェース
public interface IPrinter
{
void Print(Document document);
void StatuePrinter();
void CheckInk();
void CheckPaper();
}
public interface IScanner
{
void Scan(Document document);
void StatueScanner();
}
public interface IFax
{
void Fax(Document document);
void CheckFaxLine();
}
public interface IEmailSender
{
void Email(Document document);
void CheckInternetConnection();
}
public interface ICopier
{
void Copy(Document document);
}
// 高機能プリンターの場合
public class MultiFunctionPrinter : IPrinter, IScanner, IFax, IEmailSender, ICopier
{
public void Print(Document document)
{
Console.WriteLine("Printing document");
}
public void StatuePrinter()
{
Console.WriteLine("Checking printer status");
}
public void CheckInk()
{
Console.WriteLine("Checking ink levels");
}
public void CheckPaper()
{
Console.WriteLine("Checking paper tray");
}
public void Scan(Document document)
{
Console.WriteLine("Scanning document");
}
public void StatueScanner()
{
Console.WriteLine("Checking scanner status");
}
public void Fax(Document document)
{
Console.WriteLine("Faxing document");
}
public void CheckFaxLine()
{
Console.WriteLine("Checking fax line");
}
public void Email(Document document)
{
Console.WriteLine("Emailing document");
}
public void CheckInternetConnection()
{
Console.WriteLine("Checking internet connection");
}
public void Copy(Document document)
{
Console.WriteLine("Copying document");
}
}
// 基本プリンターの場合
public class BasicPrinter : IPrinter
{
public void Print(Document document)
{
Console.WriteLine("Printing document");
}
public void StatuePrinter()
{
Console.WriteLine("Checking printer status");
}
public void CheckInk()
{
Console.WriteLine("Checking ink levels");
}
public void CheckPaper()
{
Console.WriteLine("Checking paper tray");
}
}
// より実践的な例：ユーザー管理システム
// 悪い例
public interface IUserService
{
void Register(User user);
void Login(string username, string password);
void UpdateProfile(User user);
void DeleteAccount(int userId);
void SendPasswordResetEmail(string email);
void VerifyEmail(string token);
void GenerateApiKey(int userId);
void RevokeApiKey(int userId);
UserStats GetUserStatistics(int userId);
List<LoginHistory> GetLoginHistory(int userId);
}
// 良い例：機能ごとに分離
public interface IUserAuthentication
{
void Login(string username, string password);
void Logout(int userId);
}
public interface IUserRegistration
{
void Register(User user);
void VerifyEmail(string token);
}
public interface IUserProfile
{
void UpdateProfile(User user);
void DeleteAccount(int userId);
}
public interface IPasswordManagement
{
void ChangePassword(int userId, string oldPassword, string newPassword);
void SendPasswordResetEmail(string email);
void ResetPassword(string token, string newPassword);
}
public interface IApiKeyManagement
{
void GenerateApiKey(int userId);
void RevokeApiKey(int userId);
List<ApiKey> GetApiKeys(int userId);
}
public interface IUserAnalytics
{
UserStats GetUserStatistics(int userId);
List<LoginHistory> GetLoginHistory(int userId);
}
// 実装クラス
public class UserService : IUserAuthentication, IUserRegistration, IUserProfile
{
public void Login(string username, string password)
{
// 実装
}
public void Logout(int userId)
{
// 実装
}
public void Register(User user)
{
// 実装
}
public void VerifyEmail(string token)
{
// 実装
}
public void UpdateProfile(User user)
{
// 実装
}
public void DeleteAccount(int userId)
{
// 実装
}
}
// APIのみを使用するサービス
public class ApiOnlyUserService : IApiKeyManagement
{
public void GenerateApiKey(int userId)
{
// 実装
}
public void RevokeApiKey(int userId)
{
// 実装
}
public List<ApiKey> GetApiKeys(int userId)
{
// 実装
return new List<ApiKey>();
}
}
インターフェース分離の原則について、重要なポイントを解説します：
- 原則の本質
- クライアントが使用しないメソッドへの依存を強制されるべきではない
- インターフェースは使用する側の視点で分割すべき
- 大きなインターフェースは小さく、具体的なインターフェースに分割すべき
- メリット
- 不要な依存関係を減らせる
- システムの疎結合性が高まる
- テストが容易になる
- 実装が簡単になる
- 変更の影響範囲が限定される
- 実装例の解説
悪い例の問題点：
IWorkStation：すべての機能を1つのインターフェースに詰め込んでいるIUserService：異なる責務が混在している- 実装クラスが不要なメソッドを実装せざるを得ない
良い例の特徴：
- 機能ごとに適切に分離されている
- クライアントは必要なインターフェースのみを使用できる
- 各インターフェースの責務が明確
- 分割の判断基準
- クライアントの使用パターン
- 変更の頻度
- 機能の関連性
- 実装の共通性
- 実践的なガイドライン
- インターフェースは小さく保つ
- 単一責任の原則と組み合わせる
- クライアントの視点で設計する
- 継承よりもコンポジションを優先する
- よくある適用シーン
- 異なるクライアントが異なる機能を使用する場合
- オプション機能がある場合
- 機能の組み合わせが多様な場合
- マイクロサービスのインターフェース設計
- 注意点
- 過度な分割は避ける
- インターフェース間の関係を整理する
- 命名規則を統一する
- バージョニングを考慮する
実装時のアドバイス：
- まずは大きめのインターフェースで始める
- 使用パターンが明確になったら分割を検討
- クライアントコードの変更を最小限に抑える
- チーム内で設計方針を共有する
具体的な質問や、特定のケースについての相談がありましたら、お気軽にお申し付けください。
5. 依存性逆転の原則 (DIP)
次に「5. 依存性逆転の原則 (DIP)」について、より詳しく解説してください。
依存性逆転の原則（Dependency Inversion Principle）について、より詳細に解説させていただきます。
// 悪い例：具象クラスに直接依存している
public class NotificationService
{
private readonly SmtpEmailSender _emailSender;
private readonly SqlUserRepository _userRepository;
public NotificationService()
{
_emailSender = new SmtpEmailSender();
_userRepository = new SqlUserRepository();
}
public void NotifyUser(int userId, string message)
{
var user = _userRepository.GetById(userId);
_emailSender.SendEmail(user.Email, "Notification", message);
}
}
// 良い例：抽象に依存する
public interface IEmailSender
{
void SendEmail(string to, string subject, string body);
bool ValidateEmailAddress(string email);
}
public interface IUserRepository
{
User GetById(int id);
IEnumerable<User> GetAll();
void Save(User user);
}
public class NotificationService
{
private readonly IEmailSender _emailSender;
private readonly IUserRepository _userRepository;
public NotificationService(IEmailSender emailSender, IUserRepository userRepository)
{
_emailSender = emailSender;
_userRepository = userRepository;
}
public void NotifyUser(int userId, string message)
{
var user = _userRepository.GetById(userId);
_emailSender.SendEmail(user.Email, "Notification", message);
}
}
// 具象クラスの実装
public class SmtpEmailSender : IEmailSender
{
private readonly SmtpClient _smtpClient;
public SmtpEmailSender(string host, int port)
{
_smtpClient = new SmtpClient(host, port);
}
public void SendEmail(string to, string subject, string body)
{
// SMTP経由でメール送信
var mail = new MailMessage("from@example.com", to, subject, body);
_smtpClient.Send(mail);
}
public bool ValidateEmailAddress(string email)
{
// メールアドレスの検証ロジック
return !string.IsNullOrEmpty(email) && email.Contains("@");
}
}
// より実践的な例：eコマースシステム
// ドメインモデル（高レベルモジュール）
public interface IOrderRepository
{
Order GetById(int id);
void Save(Order order);
}
public interface IPaymentProcessor
{
PaymentResult ProcessPayment(decimal amount, string currency);
void RefundPayment(string transactionId);
}
public interface IInventoryService
{
bool CheckAvailability(string productId, int quantity);
void UpdateStock(string productId, int quantity);
}
public class Order
{
public int Id { get; set; }
public string CustomerId { get; set; }
public List<OrderItem> Items { get; set; }
public decimal TotalAmount { get; set; }
public OrderStatus Status { get; set; }
}
// ビジネスロジック（高レベルモジュール）
public class OrderProcessor
{
private readonly IOrderRepository _orderRepository;
private readonly IPaymentProcessor _paymentProcessor;
private readonly IInventoryService _inventoryService;
private readonly IEmailSender _emailSender;
public OrderProcessor(
IOrderRepository orderRepository,
IPaymentProcessor paymentProcessor,
IInventoryService inventoryService,
IEmailSender emailSender)
{
_orderRepository = orderRepository;
_paymentProcessor = paymentProcessor;
_inventoryService = inventoryService;
_emailSender = emailSender;
}
public async Task<ProcessOrderResult> ProcessOrderAsync(Order order)
{
// 在庫確認
foreach (var item in order.Items)
{
if (!_inventoryService.CheckAvailability(item.ProductId, item.Quantity))
{
return ProcessOrderResult.Failed("Insufficient inventory");
}
}
// 支払い処理
var paymentResult = _paymentProcessor.ProcessPayment(order.TotalAmount, "USD");
if (!paymentResult.Success)
{
return ProcessOrderResult.Failed("Payment failed");
}
// 在庫更新
foreach (var item in order.Items)
{
_inventoryService.UpdateStock(item.ProductId, -item.Quantity);
}
// 注文保存
order.Status = OrderStatus.Completed;
_orderRepository.Save(order);
// 確認メール送信
_emailSender.SendEmail(
order.CustomerId,
"Order Confirmation",
$"Your order #{order.Id} has been processed successfully."
);
return ProcessOrderResult.Success();
}
}
// インフラストラクチャ層（低レベルモジュール）
public class SqlOrderRepository : IOrderRepository
{
private readonly DbContext _context;
public SqlOrderRepository(DbContext context)
{
_context = context;
}
public Order GetById(int id)
{
return _context.Orders.Find(id);
}
public void Save(Order order)
{
if (order.Id == 0)
_context.Orders.Add(order);
else
_context.Orders.Update(order);
_context.SaveChanges();
}
}
public class StripePaymentProcessor : IPaymentProcessor
{
private readonly StripeClient _stripeClient;
public StripePaymentProcessor(string apiKey)
{
_stripeClient = new StripeClient(apiKey);
}
public PaymentResult ProcessPayment(decimal amount, string currency)
{
try
{
// Stripe APIを使用した支払い処理
return PaymentResult.Success("TR123");
}
catch (Exception ex)
{
return PaymentResult.Failed(ex.Message);
}
}
public void RefundPayment(string transactionId)
{
// 返金処理
}
}
// 依存性注入コンテナの設定例
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
// インターフェースと実装の紐付け
services.AddScoped<IOrderRepository, SqlOrderRepository>();
services.AddScoped<IPaymentProcessor, StripePaymentProcessor>();
services.AddScoped<IInventoryService, WarehouseInventoryService>();
services.AddScoped<IEmailSender, SmtpEmailSender>();
services.AddScoped<OrderProcessor>();
// 設定の注入
services.Configure<SmtpSettings>(Configuration.GetSection("Smtp"));
services.Configure<StripeSettings>(Configuration.GetSection("Stripe"));
}
}
依存性逆転の原則について、重要なポイントを解説します：
- 原則の本質
- 上位モジュールは下位モジュールに依存すべきではない
- 両者は抽象（インターフェース）に依存すべき
- 抽象は詳細に依存すべきではない
- 詳細は抽象に依存すべき
- メリット
- モジュール間の疎結合を実現
- テストが容易になる
- 機能の拡張が容易になる
- コードの再利用性が向上
- システムの柔軟性が増す
- 実装例の解説
悪い例の問題点：
- 具象クラスへの直接依存
- テストが困難
- 拡張が難しい
- 強い結合
良い例の特徴：
- インターフェースを介した依存関係
- 依存性注入を使用
- テスト可能な設計
- 柔軟な拡張性
- 実装のパターン
- コンストラクタインジェクション
- プロパティインジェクション
- メソッドインジェクション
- DI コンテナの使用
- 実践的なガイドライン
- 依存関係は常に抽象に対して行う
- インターフェースは使用する側で定義する
- DIコンテナを適切に活用する
- 設定の外部化を考慮する
- よくある適用シーン
- データアクセス層の抽象化
- 外部サービスとの統合
- メッセージング処理
- キャッシュ処理
- 主な実装方法 a. コンストラクタインジェクション
public class Service
{
private readonly IDependency _dependency;
public Service(IDependency dependency)
{
_dependency = dependency;
}
}
b. プロパティインジェクション
public class Service
{
public IDependency Dependency { get; set; }
}
- 注意点
- 過度な抽象化を避ける
- インターフェースの適切な粒度を保つ
- 循環依存を避ける
- DIコンテナへの過度な依存を避ける
- アンチパターン
- Service Locatorパターンの過度な使用
- 具象クラスへの直接依存
- new演算子の不適切な使用
- 静的クラスへの依存
実装時のアドバイス：
- まずはシンプルな依存関係から始める
- 必要に応じて抽象化を導入する
- テストを書きながら設計を進める
- モジュール間の境界を明確にする
具体的な質問や、特定のケースについての相談がありましたら、お気軽にお申し付けください。
SOLIDプリンシプルについて、C#のコードを用いて具体的に解説させていただきます。
それでは、各原則について詳しく説明していきます：
UserManagerとUserValidatorに責任を分割していますShapeクラスを継承することで、新しい図形を追加する際に既存のコードを変更する必要がありませんBirdの例では、各派生クラスがMove()メソッドを適切に実装していますOrderProcessorは具体的なロガーではなく、ILoggerインターフェースに依存しますこれらの原則を適切に適用することで：
特定の原則についてより詳しく知りたい場合や、他の実装例が見たい場合はお申し付けください。