1. Javaでは「曖昧な設計」がそのまま合法になる

Javaの型システムは強力ですが、設計上の曖昧さを拒否しません。

・nullが来るかどうか分からない

・状態を持つのか持たないのか曖昧

・可変である必然性がないのに可変

これらはすべて「設計が未確定」であるにもかかわらず、Javaでは問題なくコンパイルが通ります。

Javaにおいて設計品質を担保する手段は、

・コーディング規約

・レビュー

・テスト

しかありません。

つまり、言語は設計に関与しない。

2. Kotlinは「設計が曖昧なままでは書けない地点」を意図的に作る

Kotlinの本質は、機能の多さではなく、設計が未確定な箇所を“決断させる”圧力にあります。

たとえばKotlinでは、次の問いに答えない限りコードが完成しません。

・nullを許すのか

・値として扱うのか、振る舞いを持たせるのか

・状態遷移を許容するのか

これは安全性ではなく、設計を確定させるための言語的強制力です。

3. 設計破綻が表に出る位置の違い

Java

[ 設計の曖昧さ ]

      ↓

[ 実装は通る ]

      ↓

[ 利用箇所が増える ]

      ↓

[ 仕様変更で破綻 ] ← ここで初めて問題化

Kotlin

[ 設計の曖昧さ ]

      ↓

[ 型で表現できない ]

      ↓

[ コンパイル時に停止 ]

      ↓

[ 利用が広がる前に修正 ]

重要なのはKotlinは「バグを防ぐ」のではありません。設計が固まる前にコードベースが膨張するのを防ぐ。

4. Null安全の正体：依存関係の向きを固定する仕組み

Javaでは、null対応の責務は呼び出し側に分散します。

・if null

・defensive check

・想定外の利用

その結果、依存関係の向きがコードから読み取れなくなります。

Kotlinでは、nullを許す側が明示的に宣言します。これは「安全」ではなく、依存の向きを設計時に固定する行為です。

結果として、

・どこが不安定な境界か

・どこが安定した中核か

が、型として残ります。

5. Kotlinの簡潔さが効くのは「変更耐性」の一点

Kotlinが短い理由は、省略ではありません。変更に弱い構造を書きにくくしているからです。

Javaでは次のようなクラスが簡単に生まれます。

・状態もロジックも持つ

・可変だが理由が不明

・再利用され始めてから意味が変わる

Kotlinでは、「それは本当に状態を持つ必要があるのか」という問いをコードを書く段階で突きつけられます。

6. 設計の寿命という観点での比較表

7. なぜそれでもJavaは「壊れにくく見える」のか

Javaは、

・書けてしまう

・動いてしまう

ため、初期は非常に安定して見えます。

しかし設計の曖昧さは、

・利用箇所が増えた瞬間

・仕様が少し変わった瞬間

に、一気に露出します。

Kotlinは逆です。最初に止まるが、後で崩れにくい。

KotlinとJavaの違いは、安全かどうかではありません。設計が未成熟な状態でコードベースが拡張されることを許すかどうかです。Javaは自由と引き換えに問題を後回しにし、Kotlinは制約によって成長前に立ち止まらせます。どちらが優れているかではなく、設計が揺らぎやすい現場かどうかが、選択を分ける本質です。