はじめに
ソフトウェア開発において、**「変更に強く、理解しやすいコード」**を書くことは、長期的なプロジェクト成功の鍵です。Googleでは、大規模なコードベースを数十年にわたって維持するため、SOLID原則が設計の基盤として徹底されています。本記事では、実際のプロダクト開発で得た知見を交え、SOLID原則の本質と実践的な活用法を解説します。
SOLID原則とは？
SOLIDは、以下の5つの設計原則の頭文字を取ったものです。
- Single Responsibility Principle (SRP)
- Open/Closed Principle (OCP)
- Liskov Substitution Principle (LSP)
- Interface Segregation Principle (ISP)
- Dependency Inversion Principle (DIP)
これらの原則は、Robert C. Martin（Uncle Bob）によって提唱され、オブジェクト指向設計（OOP）の品質を劇的に向上させることが証明されています。
1. SRP：単一責任の原則
**「1つのクラスは1つの責任のみを持つべき」**という原則です。Googleのコードレビューでは、SRP違反がしばしば指摘されます。
❌ 悪い例
class UserManager {
void saveUser(User user) { /* DB保存 */ }
void sendEmail(User user) { /* メール送信 */ }
void validateUser(User user) { /* バリデーション */ }
}
→ データ永続化、通知、バリデーションという複数の責任が混在。
✅ 良い例
class UserRepository {
void save(User user) { /* DB保存 */ }
}
class EmailService {
void send(User user) { /* メール送信 */ }
}
class UserValidator {
void validate(User user) { /* バリデーション */ }
}
利点: 変更が局所的になり、テストや再利用が容易に。
2. OCP：開放/閉鎖の原則
**「拡張には開き、修正には閉じる」**という原則です。Googleでは、プラグインアーキテクチャやストラテジーパターンでOCPを実現します。
✅ 実践例：支払い処理
interface PaymentProcessor {
void process(Payment payment);
}
class CreditCardProcessor implements PaymentProcessor { /*...*/ }
class PayPalProcessor implements PaymentProcessor { /*...*/ }
新しい決済方法を追加する際、既存コードを変更せずに新しいクラスを実装するだけです。
3. LSP：リスコフの置換原則
**「サブタイプは親タイプと置換可能でなければならない」**という原則です。
❌ 違反例
class Rectangle {
int width, height;
void setSize(int w, int h) { ... }
}
class Square extends Rectangle {
@Override
void setSize(int w, int h) {
// 正方形のため w != h を禁止 → 挙動が不一致！
}
}
→ Rectangle を Square で置換すると、予期せぬ動作が発生。
対策: 継承よりコンポジションを優先する。
4. ISP：インターフェース分離の原則
**「クライアントが使わないメソッドに依存させてはいけない」**という原則です。
✅ Google流の実践
// モノリシックなインターフェース
interface Worker {
void code();
void debug();
void deploy();
}
// 分離したインターフェース
interface Coder { void code(); }
interface Debugger { void debug(); }
→ 開発者ごとに必要なインターフェースのみを実装。
5. DIP：依存性逆転の原則
**「具象ではなく抽象に依存せよ」**という原則です。Googleでは、DI（Dependency Injection）フレームワークがこれを支援します。
✅ 実装例
class OrderService {
private final PaymentProcessor processor;
// コンストラクタで抽象を注入
OrderService(PaymentProcessor processor) {
this.processor = processor;
}
}
利点: モックを使ったテストが容易に。
SOLID原則の本当の価値
SOLIDは「理論上の理想」ではなく、以下の現実的な課題を解決します：
- 技術的負債の蓄積を抑制
- チーム開発の効率化
- リファクタリングコストの削減
Googleの大規模プロジェクト（例：Google Search、YouTube）では、SOLID原則を適用した設計が数千万行のコードベースを支えています。
おわりに
SOLID原則は「車輪の再発明」を防ぎ、未来の自分とチームメンバーへのギフトです。最初は完璧に適用できなくても、継続的な改善が重要です。
次回は、**「Pythonで実装する最新アルゴリズムとその応用」**を解説予定です！
質問や議論はコメントへ！ 👇