はじめに
ソフトウェア開発において「設計原則（Design Principles）」は、保守性・拡張性・可読性 を高めるための基本的な考え方です。
この記事では、代表的な SOLID原則 を中心に、補助的な設計指針、UI/UX設計原則、アーキテクチャ設計原則までを整理します。
1. SOLID原則（オブジェクト指向設計の基本）
SRP：単一責任の原則（Single Responsibility Principle）
クラスやモジュールは「変更理由が一つだけ」であるべき
例（Kotlin）
// ❌ NG: ネットワーク通信とDB保存を1クラスにまとめている
class UserRepository {
fun fetchUserFromApi() { /* ... */ }
fun saveUserToDb() { /* ... */ }
}
// ✅ OK: 責務ごとに分離する
interface ApiDataSource {
fun fetchUser(): User
}
interface LocalDataSource {
fun saveUser(user: User)
}
OCP：開放/閉鎖の原則（Open/Closed Principle）
拡張に対して開かれ、修正に対して閉じているべき
// 新しい戦略を追加しても既存コードを修正しない
interface DiscountPolicy {
fun apply(price: Int): Int
}
class PercentageDiscount : DiscountPolicy {
override fun apply(price: Int) = (price * 0.9).toInt()
}
class SeasonalDiscount : DiscountPolicy {
override fun apply(price: Int) = (price - 100)
}
LSP：リスコフの置換原則（Liskov Substitution Principle）
派生クラスは基底クラスとして置き換え可能であるべき
open class Bird {
open fun fly() = println("Flying...")
}
class Sparrow : Bird()
class Penguin : Bird() {
// ❌ NG: Penguinは飛べない → LSP違反
override fun fly() = throw UnsupportedOperationException()
}
ISP：インターフェース分離の原則（Interface Segregation Principle）
利用しないメソッドを強制しない
// NG: 不要なメソッドを実装させてしまう
interface Worker {
fun work()
fun eat()
}
// OK: インターフェースを分割
interface Workable { fun work() }
interface Eatable { fun eat() }
DIP：依存関係逆転の原則（Dependency Inversion Principle）
高水準モジュールは低水準に依存せず、抽象に依存する
// 高水準コードは抽象に依存
class UserService(private val repository: UserRepository)
interface UserRepository {
fun getUser(): User
}
// 具体実装は差し替え可能
class ApiUserRepository : UserRepository { /* ... */ }
class LocalUserRepository : UserRepository { /* ... */ }
2. 補助的な設計指針
-
DRY（Don’t Repeat Yourself）
→ 重複を避ける -
KISS（Keep It Simple, Stupid）
→ シンプルに保つ -
YAGNI（You Ain’t Gonna Need It）
→ 未来の不要機能を先回り実装しない -
関心の分離（Separation of Concerns）
→ 層ごとに責務を分ける -
デメテルの法則（Law of Demeter）
→ 「友達とだけ話す」＝内部に深入りしすぎない
3. UI/UX設計原則
- 一貫性：UIパターンを統一
- アフォーダンスとフィードバック：操作と応答を明確化
- 階層性と明確さ：文字サイズ・余白・色で優先度を表現
- アクセシビリティ：誰でも利用可能に設計
- ミニマリズム：情報を必要最低限に
4. アーキテクチャ設計原則
- モジュール性：独立・交換可能な構造
- スケーラビリティ：利用者や機能の増加に対応
- テスタビリティ：単体テストが容易
- セキュリティ by Design：初期から安全性を考慮
- 保守性：拡張や修正のしやすさ
まとめ
- SOLID原則 はコードレベルの設計の柱
- DRY/KISS/YAGNI などの指針は日々の実装の助け
- UI/UX原則 はユーザー視点の品質向上
- アーキテクチャ原則 は長期的なシステムの健全性を守る
これらを意識することで、Clean Architecture の実践につながります。