はじめに
SOLID 原則の 2 つ目は OCP（開放/閉鎖の原則） です。
これは「既存コードを壊さずに拡張できる設計」を目指す重要な原則で、変更に強い設計 の基盤になります。
1. 定義
開放/閉鎖の原則（OCP） とは：
ソフトウェアの構成要素は、拡張に対して開かれており、修正に対して閉じられているべきである。
（Open for extension, Closed for modification）
つまり：
- 新しい機能を「追加（拡張）」できる
- 既存の動作を壊す「修正」は最小限にする
2. 直感的な例
OCP 違反（条件分岐が増え続けるパターン）
class DiscountCalculator {
fun applyDiscount(type: String, price: Int): Int {
return when (type) {
"percentage" -> (price * 0.9).toInt()
"amount" -> (price - 100).coerceAtLeast(0)
else -> price
}
}
}
- 新しい割引タイプを追加するたびに
whenに修正が必要 - 既存コードに手を入れる → バグリスク増大
OCP 準拠（拡張で対応できる設計）
interface DiscountPolicy {
fun apply(price: Int): Int
}
class PercentageDiscount : DiscountPolicy {
override fun apply(price: Int) = (price * 0.9).toInt()
}
class AmountDiscount : DiscountPolicy {
override fun apply(price: Int) = (price - 100).coerceAtLeast(0)
}
// 利用側は抽象に依存
class DiscountCalculator(private val policy: DiscountPolicy) {
fun calculate(price: Int) = policy.apply(price)
}
- 新しい割引方式を追加する場合は
DiscountPolicyを実装するだけ -
DiscountCalculatorは一切修正不要
3. OCP のメリット
- 変更による副作用が少ない（既存コードに触らないため）
- テスト容易性が向上（ポリシーごとに個別テストできる）
- 再利用性が高まる（既存の利用コードはそのまま新機能を使える）
- 保守性が向上（新しい要件に柔軟に対応可能）
4. 実務での適用パターン
-
戦略パターン（Strategy Pattern）
→ 上記の割引ポリシーのように振る舞いを差し替える -
DI（依存性注入）
→ 抽象に依存し、実装は注入で切り替える -
プラグイン構造
→ 新しい機能をモジュールとして追加
5. Flutter / Android での例
Flutter（Widgetの差し替え）
abstract class ThemeColor {
Color primary();
}
class LightTheme implements ThemeColor {
@override
Color primary() => Colors.blue;
}
class DarkTheme implements ThemeColor {
@override
Color primary() => Colors.black;
}
class ThemedButton extends StatelessWidget {
final ThemeColor theme;
ThemedButton(this.theme);
@override
Widget build(BuildContext context) {
return ElevatedButton(
style: ElevatedButton.styleFrom(backgroundColor: theme.primary()),
onPressed: () {},
child: Text("OCP Example"),
);
}
}
Android（DI + Strategy）
interface Logger {
fun log(message: String)
}
class ConsoleLogger : Logger {
override fun log(message: String) = println("Console: $message")
}
class FileLogger : Logger {
override fun log(message: String) { /* ファイル出力 */ }
}
class UserService(private val logger: Logger) {
fun createUser(name: String) {
logger.log("User created: $name")
}
}
→ ログの出力先を変えても UserService は修正不要
6. よくある誤解
-
「既存コードを一切修正してはいけない」ではない
→ インターフェース定義など「拡張のための入口」を設ける最初の修正は必要 -
「全部を抽象化すればよい」ではない
→ 過剰な抽象は逆に複雑性を増すので、変更可能性が高い部分だけに適用
まとめ
- OCP = 変更に強い構造
- 「修正」ではなく「拡張」で要件対応するのが基本姿勢
- 実務では Strategy / DI / Plugin構造 がよく使われる
- SRP と組み合わせるとより効果的（責務を分けて、拡張で追加）