2012-04-12 11 views
0

Ich habe auf Java und Oop Design gelesen. Eine der Übungen bestand darin, ein System zu entwerfen, das astronomische Objekte und einige grundlegende Eigenschaften von ihnen enthält.Java oop Design Verifikation

Das System muss Sterne, Galaxien und Planeten enthalten.

Jedes Objekt hat einen Typ, zB für Sterne; Zwerg, Riese und Normal

Beginnt auch eine Farbe zu haben.

Also begann ich weit mit einer abstrakten Basisklasse für alle diese AstronomicalObject Objekte genannt:

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

Ich habe dann drei Klassen Star, Galaxy und Planeten, die diese Klasse erweitern. Für jeden Typ dieser Objekte habe ich zusätzliche Unterklassen gebildet, dh DwarfStar, der Star erweitert. Ist das eine akzeptable Idee? Die zusätzlichen Klassen fühlen sich etwas redundant:

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

Für die Farbattribute ich dies tat:

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; 
    } 
} 

So ein Stern-Objekt erstellen ich verwenden würde:

DwarfStar ds = new DwarfStar(Star.YELLOW); 

Leider doesn das Buch Habe keine Antworten Seite oder diskutiere diese Übung, also habe ich mich gefragt, ob meine Lösung ein gültiges Design ist. Oder wenn es verbessert werden könnte?

+5

es ist besser, Enum anstelle von String-Konstanten zu verwenden – maks

+0

Danke für das zeigen, –

+2

Ich denke, in diesem einfachen Übung ist es nicht notwendig, die Klasse Stern Unterklasse. Wenn nur das Feld SIZE hinzugefügt werden soll, wäre es besser, einen Feldtyp in der Star-Klasse zu erstellen. Dies kann mit einer Enumeration realisiert werden. Meiner Meinung nach sollten Sie die Vererbung nur verwenden, wenn Sie sie wirklich brauchen, weil sie die Komplexität erhöht. – Don

Antwort

3

Ist das völlig sinnlos?

wenn Ihre drei Objekte haben eine type wie Sie gesagt haben, dann nein, es nicht nutzlos ist, wie Sie in der Lage sein wird, nur einen Setter und Getter in der Superklasse zu schreiben, anstatt sie in jeder Unterklasse zu implementieren. Tatsächlich ist eine Oberklasse nicht nutzlos, wenn jede Unterklasse eine gemeinsame Eigenschaft hat.

Dann für die Farben könnten Sie eine Enum anstelle von statischen Variablen verwenden:

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

und sich zum Beispiel mit Colours.RED zugreifen.

+0

Danke für die enum, das ist eine bessere Lösung. –

2

Dies ist sehr gültig und es gibt, wenn überhaupt, nur geringfügige Verbesserungen.

Die Klasse AstronomicalObject scheint an diesem Punkt sinnlos zu sein, sollte aber beibehalten werden, wenn Sie etwas in der Zukunft hinzufügen möchten oder wenn Sie entscheiden, dass jedes astronomische Objekt eine Masse oder Form oder was auch immer hat. Auch bei größeren Softwarelösungen könnte dies notwendig sein.

2

Ich denke, da dies eine OOP-Übung ist, ist es wichtig zu überlegen, was Planeten Sterne und Galaxien gemeinsam haben. Vielleicht gilt Farbe nur für Sterne und Planeten? Was ist mit Größe? Sie können diese Übung wiederholen, indem Sie mehr darüber nachdenken, wie Sie die Attribute Ihrer Klassen auf diese Weise beschreiben können.

1

Zusammensetzung wird mehr als Vererbung in OO-Design verwendet. So ist ein Galaxy zusammengesetzt aus Star s und Planet s. Dein Code sollte das zeigen. Gehört ein Planet immer zu einem einzigen Star? Wenn ja, dann solltest du das irgendwie zeigen.

Andere Antworten darauf hinweisen, dass Sub-Typisierung Star ist nicht notwendig für die trivialen Fälle, die Sie gaben, aber möglicherweise, wenn Sie all the categories of astronomical objects berücksichtigt. Ich denke, die AstronomicalObject ist nur wirklich notwendig, wenn es tatsächlich eine Funktion oder ein Merkmal gibt, das allen Unterklassen gemeinsam ist.

Es klingt wie du beginnst, also ist die Übung, dich vertraut zu machen mit Zusammensetzung und Vererbung. Eine Einschränkung von OO Design-Übungen, die reale Objekte modellieren, ist, dass sie nicht die Anforderungen der Software Sie entwerfen. Doch diese Anforderungen sind sehr wichtig, wenn Sie das OO-Design-Modell machen. Wenn beispielsweise die von Ihnen entworfene Software Himmelsobjekte katalogisieren soll, die für Benutzer von Amature-Teleskopen sichtbar sind, ist das Hinzufügen einer Klasse für BlackHole (vorausgesetzt, sie ist bei optischen Teleskopen nicht sichtbar) möglicherweise nicht erforderlich.