0

私はJavaとoopの設計について読んでいます。演習の 1 つは、天体とその基本的な属性を保持するシステムを設計することでした。

システムは星、銀河、惑星を保持する必要があります。

各オブジェクトには、星などのタイプがあります。ドワーフ、ジャイアント、ノーマル

スタートにも色があります。

これまでのところ、AstronomicalObject と呼ばれるこれらすべてのオブジェクトの抽象基本クラスから始めました。

public abstract class AstronomicalObject {
  //Is this totally pointless?
}

次に、このクラスを拡張する 3 つのクラス Star、Galaxy、Planet を作成しました。これらのオブジェクトのタイプごとに、追加のサブクラス、つまり Star を拡張する DwarfStar を作成しました。これは受け入れられる考えですか？追加のクラスは少し冗長に感じます:

public class DwarfStar extends Star{
  public final String SIZE = "DWARF";
  public DwarfStar(String colour) {
    super(colour);
  }
}

色の属性については、次のようにしました。

public class Star extends AstronomicalObject{
  public final static String YELLOW = "YELLOW";
  public final static String RED = "RED";
  public final static String WHITE = "WHITE";
  public final static String SIZE = "NORMAL";
  private String colour;

  public Star(String colour) {
    this.colour = colour;
  }

  public String getColour(){
    return this.colour;
  }
}

したがって、星のオブジェクトを作成するには、次を使用します。

DwarfStar ds = new DwarfStar(Star.YELLOW);

残念ながら、この本には回答ページがなく、この演習についても説明されていないため、私の解決策が有効な oop 設計であるかどうか疑問に思っていました。または、それを改善できる場合は？

4

4 に答える 4

3

これはまったく無意味ですか？

あなたが言ったように3つのオブジェクトにaがあるtype場合、各サブクラスに実装する代わりに、スーパークラスにセッターとゲッターを1つだけ書くことができるので、無駄ではありません。実際、すべてのサブクラスに共通のプロパティがある場合、スーパークラスは役に立たないわけではありません。

次に、静的変数の代わりに列挙型を使用できます。

public enum Colours{
    YELLOW, RED, WHITE, NORMAL
}

Colours.REDたとえば、それらにアクセスします。

于 2012-04-12T19:36:11.590 に答える
2

これは非常に有効であり、あるとしても、わずかな改善があります。

このAstronomicalObject時点ではクラスは無意味に見えますが、将来何かを追加したい場合、またはすべての天体に質量や形状などがあると判断した場合は、保持する必要があります。また、より大きなソフトウェアソリューションでは、これが必要になる場合があります。

于 2012-04-12T19:39:10.450 に答える
2

これはOOPの演習であるため、惑星の星と銀河に共通するものを考慮することが重要だと思います。たぶん、色は星と惑星にのみ適用されますか？サイズはどうですか？この方法でクラスの属性をどのように説明できるかを考えて、この演習をやり直すことをお勧めします。

于 2012-04-12T19:40:20.193 に答える
1

オブジェクト指向設計では、継承よりも構成が使用されます。したがって、aGalaxyはStars とPlanets で構成されます。あなたのコードはそれを示すはずです。a はPlanet常に単一の に属しStarますか? もしそうなら、それを何らかの方法で示す必要があります。

他の回答は、あなたが与えた些細なケースではサブタイピングは必要ないことを指摘していますが、天体のすべてのカテゴリStarを考慮した場合はそうなる可能性があります。すべてのサブクラスに共通する機能または特性が本当にある場合にのみ、本当に必要だと思います。AstronomicalObject

初心者のように聞こえるので、構成と継承に慣れるための演習を行います。実世界のオブジェクトをモデル化する OO 設計演習の注意点は、設計中のソフトウェアの要件が得られないことです。しかし、OO 設計モデルを作成する場合、これらの要件は非常に重要です。たとえば、設計しているソフトウェアが、アマチュア望遠鏡ユーザーに見える天体をカタログ化することになっている場合、BlackHole のクラスを追加する必要はありません (アマチュア光学望遠鏡では見えないと仮定します)。

于 2012-04-13T02:23:48.067 に答える