kentaro yataのポートフォリオサイトのロゴ

Frontend Engineer & Programmer
Sapporo, Hokkaido, Japan

About Me
At The Mountains Of OOP

At The Mountains Of OOP

統合開発環境で遊ぶ、オブジェクト指向とクラス設計を学ぶ演習

Tech:
  • Java

オブジェクト指向とクラス設計を演習で学ぶ

Javaの学習について整理するために開始した演習です。

① テーマ

『狂気の山脈にて』(著 H.P.ラヴクラフト)のクトゥルフ神話TRPG(CoC)風ゲームブック。
統合開発環境(Eclipseを使用)のコンソールで動作する。

  • キャラクタークリエイト
  • ダイスによる技能判定
  • 体力などのパラメータ管理
  • シーン管理
  • エンディング管理

② 演習目標

  1. OOPにおける「オブジェクトの役割」を体感する。
  2. 役割を意識した設計をできるようになる。
  3. 知らないJava APIや組み込みメソッドを試す。

③ 開発を終えて学んだこと

1. 「クラスを作る」とは、責務を決めることと理解できた

開発を始めた当初は、

  • とりあえずクラスを分ける
  • とりあえずメソッドを作る

という感覚でしたが、進めるにつれて

「このクラスは何を知ってよくて、何を知らないべきか」を常に考えるようになりました。

2. 「インスタンスを返す」ことへの理解が深まった

createSpec()build() のようにメソッドがオブジェクトを返す設計に最初は戸惑いがありました。

しかし、

  • Mainで受け取る」
  • Scene で受け取って Context に格納する」

という流れを何度も書くうちに、

インスタンスを返す=「その場で完成した成果物を、次の責務へ手渡すこと」

だと腑に落ちました。

3. 参照渡しは責務分離を助けるものだと理解できた

ScannerGameMaster を渡すとき、

  • 「二重管理にならないか?」
  • 「影響範囲が分からなくならないか?」

という不安がありました。

しかし実際には、

  • 同じ参照を共有しているからこそ
  • 状態が一貫して保たれる

というメリットを体感できました。

4. 抽象クラス・インターフェースの「意味」が実感できた

Sceneinterface / abstract class として扱ったことで、

  • play() という共通インターフェース
  • 実装は各 Scene に任せる

という形が自然に成立しました。

これにより、

  • 「次はどの Scene へ行くか」
  • 「条件分岐はどこで行うか」

ポリモーフィズムに任せられるようになりました。

④ 総括

このプロジェクトを通して、

  • OOPは「書き方」ではなく「考え方」だということ
  • クラスは「便利な箱」ではなく「責務の境界」だということ
  • 設計は最初から完璧でなくていいが、途中で考え直せる構造が大事だということ

を強く実感しました。