オブジェクト指向の考え方について - Java

Question

オブジェクト指向初心者です。スッキリわかるJava入門にて学習中です。

現在、簡単な戦闘ゲームを作成しているのですが、そこでクラスをどのように設計していけば良いかわからず、質問させていただきました。

ゲームの登場人物は以下の二つに分類できます。
・Heroクラス（勇者パーティー）
・Enemyクラス（敵）

まず、上の二種類のクラスの大元となるCharacterクラス（登場人物）を作成しました。

package gradle_practice.rpg.characters;

import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Getter;
import lombok.Setter;
import lombok.experimental.SuperBuilder;

@Getter
@Setter
@AllArgsConstructor
@SuperBuilder
public class Character {
  @Builder.Default
  protected String name = "名無し";
  @Builder.Default
  protected int hp = 1;
  @Builder.Default
  protected int mp = 0;

// Some code...
}

次に先程のHeroクラスとEnemyクラスを作成しました。
（以下、Heroクラスのみ掲載。Enemyクラスも殆ど同じ）

package gradle_practice.rpg.characters;

import lombok.experimental.SuperBuilder;

@SuperBuilder
public class Hero extends Character {
// 何もない
}

しかし、現状分類のみ行ないたいという状態のため、クラスにプロパティやメソッドが存在しない状態となってしまいました。（lombokによるコンストラクタの定義を除く）これは一般的に推奨されることなのでしょうか。また、推奨されない場合、代替策をご教授いただければと思います。

以上となります。よろしくお願いいたします。

Answer 1

現状分類のみ行ないたいという状態のため、クラスにプロパティやメソッドが存在しない状態となってしまいました。（lombokによるコンストラクタの定義を除く）これは一般的に推奨されることなのでしょうか。

今後を見越す観点の回答
確かに現時点ではHeroとEnemyの差分は無いんですけれど、
それは今後の拡張で埋まっていくと思います。クラスを分けた方が良いでしょう。

質問に直球で答える回答
分類のためにクラス分けをすることは、実はしばしばあります。
インターフェースで表現することが多く、実際java.lang.Cloneableは空です。

空のインターフェースを実現しても当然動作に変わりはありませんが、
『複製が可能であると表明しているクラスのインスタンスだけ』受け付ける処理が書けます。

---

HeroとEnemyエネミーについては分けるべきだと私は思いますが、
例えばEnemyクラスを特化させたSlimeクラスを作るべきか？と問われると少し迷います。

どっちが正解とも言いづらいケースも多いのです。

勉強目的であれば、練習も兼ねて両パターン試してみても良いかもしれません。
それぞれの長所と短所を体感できれば、ちょうど良い混ぜ具合が分かってくる筈です。

Comments

[tyningsass]

>HeroとEnemyエネミーについては分けるべきだと私は思いますが、
>例えばEnemyクラスを特化させたSlimeクラスを作るべきか？と問われると少し迷います。

この場合、Slimeクラスはどのように実装するのでしょうか。
現状、質問した方法以外の分類方法の検討がつかない状態です。Enemyクラスの子にSlimeクラスなどの具体的な敵を定義していく予定なのですが、これはあまり良くない設計なのでしょうか。

[LouiS0616]

スライム、スライムベス、ホイミスライム、メタルスライム、大量にスライムを用意するのであればその根底のSlimeクラスがあっても良いでしょう。
ただ個々の種のクラスを用意する必要があるかというと私は否定的で、クラスが増えるメリットより煩雑になること・複雑になることのデメリットの方が勝ると思うからです。

どちらを取るかは今後の拡張の方針にもよりますし、それこそ実装者の好みにもよります。

[LouiS0616]

例えば「名前が7文字のモンスターには攻撃力2倍！」という特殊な武器を作るとします。
そういうときは名前をフィールドで取り回す設計の方が圧倒的に実装が簡単です。

クラスMetalSlimeにnameフィールドを作るのは冗長ですし、if(obj.getClass().getName().length() == 7) みたく書くのも筋が良くないです。

Answer 2

設計の目的を考えましょう。

ゲームの登場人物は以下の二つに分類できます。

この時点で、共通の属性を持っていてCharactorというクラスに汎化できる、という発想で作った事と、これらはそのゲームのプログラム中で明確に区別されるべきものである、という前提があるはずです。

ここまでは問題はない事にしましょう。（Charactorに敵を含むかどうかはそのゲームの仕様次第でベストな設計なのかどうか分かれそうですが）

クラスにプロパティやメソッドが存在しない状態となってしまいました。

以上が設計目的を満たしているという事は、HeroやEnemyというクラスはプログラム上明確に個々に扱うべきシーンが違うはずです。（共通する処理はCharactorを使うはずなので）

これはコードを読み書きする上で重要です。

それらの実装が、親クラスで全て賄われているか、独自の実装を持っているのかは、従属的な問題でしかないです。個別の実装を持っているケースの方が大多数だと思いますが、仕様上求められていないコードを書くわけもありません。

あなたが決めた「仕様」で「分類をする」ところまで決まっているのであれば、そこにどんなメソッドやプロパティが生えているのかもまた、あなたが決めた「仕様」次第です。そこに求めるものが無いのに、何かを実装する事はありえないでしょう。

だからといって、「いまメソッド・プロパティが実装されていないから」という理由で「分類をする」という仕様を覆してHero、Enemyクラスを削除するのは、実装が設計に影響を与えている事になり、それは順序が逆転しています。最初の「分けて扱うべき」という設計上の要求はどこにいったの？という話です。

設計上必要だから分類したのであれば、その中身がどうなっているのかで設計を変えるのは、むしろ一般的に言って悪手です。

Comments

[gentaro]

なお、これは随時「設計」を見直して実装が進むという仮定で書いてます。
設計がもうFIXしており、Hero, Enemyを区別する必要がない（独自の属性等が全く無く、どんな場面でも同じ扱いをする事が明らか）のであれば、Charactorだけあれば良いんじゃないですかね。

[tyningsass]

>以上が設計目的を満たしているという事は、HeroやEnemyというクラスはプログラム上明確に個々に扱うべきシーンが違うはずです。（共通する処理はCharactorを使うはずなので）

今回の場合、暫定的に以下の実装をしたかったため分類しました。
・ヒーラーの回復魔法を仲間のみ対象とする

>だからといって、「いまメソッド・プロパティが実装されていないから」という理由で「分類をする」という仕様を覆してHero、Enemyクラスを削除するのは、実装が設計に影響を与えている事になり、それは順序が逆転しています。

やはりそうですよね。空のクラスというものに少々抵抗があったため、有識者の方の意見を聞きスッキリしました。

Answer 3

現状分類のみ行ないたいという状態のため、
クラスにプロパティやメソッドが存在しない状態
これは一般的に推奨されることなのでしょうか

構いません。むしろ、実装（プロパティやメソッド）が存在しないからといって、
本来別のふたつのクラスをひとつにまとめる、という方が非推奨でしょう。

本来の設計上、クラスがひとつなのかふたつなのか、という方が重要です。
味方と敵が区別される、混同されない、という**分類（型）**が大事なのです。

---

クラス型のOOP言語なら大抵そうでしょうが、とくに「Java」という言語は、
抽象化や型設計を大事にしており、「インターフェイス」という
実装が空でいい仕組みを作っていることからも、それが容易に推察できます。

空のクラスを残す意味は、型や分類の方が、実装より大事な場合が多々あるからです。
最初のうちは不思議に思えるかもしれませんが、その理由は次のようなことです。

---

Javaは複数人で大規模開発することを想定している言語なので、
記述が多少冗長になっても、型安全の方を重視して設計されています。

それは、間違ったデータを突っ込まれてバグが起こる可能性について、
規模が大きいと被害が大きいし、開発人数が多いと起こる確率も上がるから。
空のクラスより、過剰な実装の方が、より注意する必要があるわけです。

そこで、「型という鍵」とカプセル化で、個室（クラス）を管理しようと。
ひとりで住んでる家の部屋には鍵を掛けないけど、
ホテルならひとつひとつの部屋に鍵を掛けますよね。

もし、2人用の部屋に1人で泊まる、という人が2人いても、
フロントが勝手に部屋を移して、相部屋にはしないでしょう？
ホテルでは部屋の面積より、顧客管理（と信用）の方が大事なのです。

同様にJavaは堅い言語なので、、行数より設計（の反映）の方が大事です。
（Rubyだと、ダックタイピングやメタプログラミングで、もう少し緩いですが）