質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Java

Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

オブジェクト指向

オブジェクト指向プログラミング(Object-oriented programming;OOP)は「オブジェクト」を使用するプログラミングの概念です。オブジェクト指向プログラムは、カプセル化(情報隠蔽)とポリモーフィズム(多態性)で構成されています。

Q&A

解決済

3回答

867閲覧

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

tyningsass

総合スコア8

Java

Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

オブジェクト指向

オブジェクト指向プログラミング(Object-oriented programming;OOP)は「オブジェクト」を使用するプログラミングの概念です。オブジェクト指向プログラムは、カプセル化(情報隠蔽)とポリモーフィズム(多態性)で構成されています。

2グッド

1クリップ

投稿2021/07/11 13:24

編集2021/07/11 13:29

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

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

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

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

java

1package gradle_practice.rpg.characters; 2 3import lombok.AllArgsConstructor; 4import lombok.Builder; 5import lombok.Getter; 6import lombok.Setter; 7import lombok.experimental.SuperBuilder; 8 9@Getter 10@Setter 11@AllArgsConstructor 12@SuperBuilder 13public class Character { 14 @Builder.Default 15 protected String name = "名無し"; 16 @Builder.Default 17 protected int hp = 1; 18 @Builder.Default 19 protected int mp = 0; 20 21// Some code... 22} 23

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

java

1package gradle_practice.rpg.characters; 2 3import lombok.experimental.SuperBuilder; 4 5@SuperBuilder 6public class Hero extends Character { 7// 何もない 8} 9

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

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

K_3578, __horito👍を押しています

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答3

0

ベストアンサー

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

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

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

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


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

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

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

投稿2021/07/11 13:50

編集2021/07/11 13:59
LouiS0616

総合スコア35658

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

tyningsass

2021/07/11 14:35

>HeroとEnemyエネミーについては分けるべきだと私は思いますが、 >例えばEnemyクラスを特化させたSlimeクラスを作るべきか?と問われると少し迷います。 この場合、Slimeクラスはどのように実装するのでしょうか。 現状、質問した方法以外の分類方法の検討がつかない状態です。Enemyクラスの子にSlimeクラスなどの具体的な敵を定義していく予定なのですが、これはあまり良くない設計なのでしょうか。
LouiS0616

2021/07/12 09:50

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

2021/07/12 09:55

例えば「名前が7文字のモンスターには攻撃力2倍!」という特殊な武器を作るとします。 そういうときは名前をフィールドで取り回す設計の方が圧倒的に実装が簡単です。 クラスMetalSlimeにnameフィールドを作るのは冗長ですし、if(obj.getClass().getName().length() == 7) みたく書くのも筋が良くないです。
guest

0

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

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

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

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

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

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

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

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

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

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

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

投稿2021/07/11 14:21

編集2021/07/11 14:23
gentaro

総合スコア8949

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

gentaro

2021/07/11 14:26 編集

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

2021/07/11 14:44

>以上が設計目的を満たしているという事は、HeroやEnemyというクラスはプログラム上明確に個々に扱うべきシーンが違うはずです。(共通する処理はCharactorを使うはずなので) 今回の場合、暫定的に以下の実装をしたかったため分類しました。 ・ヒーラーの回復魔法を仲間のみ対象とする >だからといって、「いまメソッド・プロパティが実装されていないから」という理由で「分類をする」という仕様を覆してHero、Enemyクラスを削除するのは、実装が設計に影響を与えている事になり、それは順序が逆転しています。 やはりそうですよね。空のクラスというものに少々抵抗があったため、有識者の方の意見を聞きスッキリしました。
guest

0

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

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

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


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

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


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

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

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

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

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

投稿2021/07/27 02:07

LLman

総合スコア5592

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問