Thema: Vererbung Ober-/Unterklassen

D

David Nienhaus

Gast
Hallo liebe Leute,

ich bin gerade dabei eine Klasse "Raum" in zwei Unterklassen "Geschaeft" und "StandartRaum" zu unterteilen. Was ich noch nicht ganz verstehe ist folgendes:

Ich möchte in meiner Hauptklasse überprüfen, ob ein Raum ein Geschäft bzw ein StandartRaum ist. Gibts dafür eine elegante Lösung?

Liebe Grüße
David
 
D

David Nienhaus

Gast
Ich glaube ich habe schon selbst die Antwort gefunden :

if(aktuellerRaum.getClass() == Geschaeft.class){

:)
 

Javinner

Top Contributor
Java:
public abstract class Room
{
}
public class BedRoom extends Room
{ 
}
public class WorkRoom extends Room
{  
}

public class Rooms
{
  
    public static void main(String[] args)
    {
        Room bedroom = new BedRoom();
        Room workroom = new WorkRoom();
      
        whoAreYou(bedroom);
        whoAreYou(workroom);
      
    }
  
    static void whoAreYou(Room room)
    {
        if(room instanceof BedRoom)
        {
            System.out.println("Here you can sleep");
        } else if(room instanceof WorkRoom)
        {
            System.out.println("Here you can work");
        }
    }
  
}
/** Output */
Here you can sleep
Here you can work
instanceof
 

mihe7

Top Contributor
Die Antwort, wie man das technisch löst, hast Du ja bereits bekommen.

Einmal unabhängig davon stellen sich zwei Fragen:
  1. Aus welchem Grund möchtest Du das in der Raumklasse machen?
  2. Inwiefern unterscheiden sich Geschäfts- und Standardraum voneinander?
 
D

David Nienhaus

Gast
Also mit Hauptklasse war nicht die Raumklasse gemeint. Also vielleicht einmal zum Kontext des Programms:
Es ist ein sehr einfaches textbasiertes Spiel mit verschiedenen RÄumen zwischen denen man sich bewegen kann.
In meiner Hauptklasse "Spiel" möchte ich nun abfragen, ob der aktuelle Raum ein Geschäft oder ein normaler Raum ist. Der Unterschied soll erstmal nur darin bestehen, dass ein Geschäft einen Kassierer hat und dass ein Geschäft "verschlossen" sein kann, sobald man einen Gegenstand aufnimmt und ihn noch nicht bezahlt hat.
 
D

David Nienhaus

Gast
Das Spiel an sich läuft schon, jetzt möchte ich aber versuchen Vererbungen zu implementieren und alles auf mehere Unterklassen aufzuteilen, da wir dies momentan in der Vorlesung haben.
 

mihe7

Top Contributor
Schön, sowas in der Richtung habe ich mir schon gedacht :)

Das Problem ist, dass Du in der Spielklasse jetzt bei jeder Gelegenheit überprüfen müsstest, vom welchem Typ der Raum ist. Das ist nicht Sinn und Zweck der Geschichte.

Überlege Dir, wie Du das ohne "instanceof" hinbekommen könntest.

Mal ein Beispiel:
Java:
class Form { }
class Rechteck extends Form { ... }
class Kreis extends Form { ... }
class Spielfeld {
    void zeichne(Form f) {
        ...
        if (f instanceof Rechteck) { zeichneRechteck((Rechteck) f); }
        else if (f instanceof Kreis) { zeichneKreis((Kreis) f); }
    }
    ....
}

Das ist nicht gut: wenn Du jetzt eine Klasse Dreieck einführst, musst Du die Klasse Spielfeld anpassen und wieder auf f instanceof Dreieck prüfen.

Alternativ könnte die Form sich selbst zeichnen, dann sähe die Methode in Spielfeld nur noch so aus:
Java:
    void zeichne(Form f) {
        ...
        f.zeichne();
    }
 

Neumi5694

Top Contributor
mihe7 hat's schon ganz gut beschrieben.
Die Oberklasse sollte nur gemeinsame Eigenschaften besitzen, alles andere muss sollte in den Unterklassen passieren, sonst bräuchte man jene ja gar nicht. Um genau zu sein, sollte die Oberklasse gar nicht wissen, dass es die Unterklassen überhaupt gibt.
Wenn man so vorgehen will, wär's besser, der Oberklasse eine Eigenschaft (EnumVariable als Beispiel) zuzuweisen, welche beschreibt, worum es sich handelt.

Überlege auch, Logik von Daten zu trennen. Ein externer Handler wäre gerade bei einem Spiel wahrscheinlich sinnvoller.
 

Neumi5694

Top Contributor
Ein anschauliches Beispiel aus dem Real Life: Eine Musikdatei muss sich nicht selbst abspielen können, es ist sinnvoll, dass dies eine spezialisierte Verarbeitungsstation erledigt, damit nicht jede Musikdatei selbst den Code des Betriebssystems und alle Soundkartenschnittstellen kennen muss.

Ein anderes Beispiel:
(Graphics)g.draw(new Rectangle(...))
Das Rectangle selbst beinhaltet keine Zeichenlogik und das ist auch gut so.
Es erfüllt aber einen Interface-Standard (Shape), der von g gezeichnet werden kann.

Wie wäre es mit Zinsberechnung? Soll ein Bankkonto oder gar der aktuelle Kontostand in der Lage sein, Zinsen selbst auszurechnen? Auf die Idee würde keiner kommen und das zu Recht.

Das "sich selber zeichnen" habe ich jahrelang so praktiziert - bis das Ausgabeziel ein anderes wurde, dann ging der Schuss nach hinten los. Auch sollten die Elemente sich selbst anhand von Parametern verarbeiten, selbst dafür sorgen, dass die Zieldaten erzeugt wurden - das hat sich im Nachhinein ebenfalls als Fehler erwiesen.
Man verliert enorm viel Flexibilität, wenn komplexe Vorgänge innerhalb der Datenklassen passieren und das Ganze wird sehr schwer zu warten, die Schnittstellen werden zu unübersichtlich. Einfache Vorgänge, welche wirklich nur die Daten selbst betreffen, können natürlich rein. Aber die Verarbeitung der Daten - vor allem mit verschiedenen Zielen - sollte außerhalb passieren.
 

mrBrown

Super-Moderator
Mitarbeiter
Ein anderes Beispiel:
(Graphics)g.draw(new Rectangle(...))
Das Rectangle selbst beinhaltet keine Zeichenlogik und das ist auch gut so.
Es erfüllt aber einen Interface-Standard (Shape), der von g gezeichnet werden kann.
Das amüsante daran, dass du @mihe7 zustimmst, dann aber genau das Gegenteil ergänzt und ihr auch noch quasi das gleiche Beispiel für gegenteilige Argumente bringt, seh grad wohl nur ich?



Ich würde bei allen drei Punkten nur bedingt zustimmen, dass da die zu dem Objekt gehörende Login von den Daten getrennt wird.

Die ersten zwei Punkte sind je nach Sichtweise Trennung UI - Model.
Beim zweiten Punkt ist es außerdem einfach sinnvolles Refactoring. Es gibt im Zeichnen keine Unterscheid zwischen allen "normalen" Objekten, von daher ist das völlig logisch, das auszulagern.

Zinsen berechnen ist für mich auch nur in Teilen Aufgabe eines Kontos, und da es vermutlich nicht "die eine" Zinsberechnung geben wird, würde man das auch auslagern und einfach das Strategypattern nutzen.

Das "sich selber zeichnen" habe ich jahrelang so praktiziert - bis das Ausgabeziel ein anderes wurde, dann ging der Schuss nach hinten los. Auch sollten die Elemente sich selbst anhand von Parametern verarbeiten, selbst dafür sorgen, dass die Zieldaten erzeugt wurden - das hat sich im Nachhinein ebenfalls als Fehler erwiesen.
Man verliert enorm viel Flexibilität, wenn komplexe Vorgänge innerhalb der Datenklassen passieren und das Ganze wird sehr schwer zu warten, die Schnittstellen werden zu unübersichtlich. Einfache Vorgänge, welche wirklich nur die Daten selbst betreffen, können natürlich rein. Aber die Verarbeitung der Daten - vor allem mit verschiedenen Zielen - sollte außerhalb passieren.
Das Thema passt besser hierzu: OO ist gescheitert
Das was du beschreibst, hat nicht mehr viel mit OO zu tun - was nicht ohne Grund ziemlich verbreitet ist. Die Probleme die du beschreibst, klingen eher nach Architekturproblemen, die man mit besserem, und trotzdem Objekt-Orientiertem, Design besser hätte lösen können.
 
Zuletzt bearbeitet:

Neumi5694

Top Contributor
Das amüsante daran, dass du @mihe7 zustimmst, dann aber genau das Gegenteil ergänzt und ihr auch noch quasi das gleiche Beispiel für gegenteilige Argumente bringt, seh grad wohl nur ich?
Ja, ich denke schon. Nach wie vor gilt: Die Oberklasse sollte nach Möglichkeit nichts von den Unterklassen wissen.
Und ja, das sind Beispiele dafür, wo ein sich selbst verwaltendes Objekt nicht gut funktioniert, danach hast du ja gefragt.
Wenn du Beispiele willst, wo es funktioniert, darfst du gerne danach fragen.
 

mrBrown

Super-Moderator
Mitarbeiter
Ja, ich denke schon. Nach wie vor gilt: Die Oberklasse sollte nach Möglichkeit nichts von den Unterklassen wissen.
Und ja, das sind Beispiele dafür, wo ein sich selbst verwaltendes Objekt nicht gut funktioniert, danach hast du ja gefragt.
Die Oberklasse muss nie was über die Unterklassen wissen - in keinem würde aber das Vorhandensein bze nicht-Vorhandensein einer Oberklasse irgendwas ändern ;)
 

mihe7

Top Contributor
Das amüsante daran, dass du @mihe7 zustimmst, dann aber genau das Gegenteil ergänzt und ihr auch noch quasi das gleiche Beispiel für gegenteilige Argumente bringt, seh grad wohl nur ich?
Darin sehe ich keinen Widerspruch: vgl. Graphics#draw(Shape) und Component#paint(Graphics).

Die Formulierung "Trennung von Daten und Logik" ist auf Objektebene allerdings ungünstig, denn das hört sich so an, als dürfte ein Objekt, das eine Funktionalität anbietet, keine Felder enthalten.
 

mrBrown

Super-Moderator
Mitarbeiter
Darin sehe ich keinen Widerspruch: vgl. Graphics#draw(Shape) und Component#paint(Graphics).
Hm, in "Form [kann] sich selbst zeichnen" und "[Form] beinhaltet keine Zeichenlogik" ist kein Widerspruch?

Und in dem Fall: Shape ist eine geometrische Form, zu deren Logik gehört es halt auch nicht, gezeichnet zu werden - im Gegensatz zu Component, zu dessen Logik das Zeichen durchaus gehört, und welchem es deshalb überlassen wird ;)
 

mihe7

Top Contributor
Mir ging es lediglich darum, mit einem Beispiel zu zeigen, wie der Fragesteller ohne instanceof auskommt. Ich hätte die Klassen auch einfach A, B und C nennen können und die Methoden doSomethingWithB, doSomethingWithC bzw. domeSometing.

@Neumi5694 hat ergänzt, dass er (=Fragesteller) auch zwischen Daten und Logik trennen soll. Das sind völlig verschiedene Dinge.

Hätte ich statt Form "Component" verwendet, dann stünden jetzt die beiden Aussagen "Component kann sich selbst zeichnen" und "Shape beinhaltet keine Zeichenlogik" im Raum.

Shape ist eine geometrische Form, zu deren Logik gehört es halt auch nicht, gezeichnet zu werden
Ich denke, das sollte "Trennung von Daten und Logik" auch aussagen.
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
C Programmvorstellung & Frage zum Thema Geschäftsform Allgemeine Java-Themen 51
H Kennt sich jemand mit Eclipse und dem Thema Jar-File aus ? Allgemeine Java-Themen 6
L thema gelöscht Allgemeine Java-Themen 0
T Fragen zum Thread-Thema Allgemeine Java-Themen 4
T Fragen zum Thread-Thema Allgemeine Java-Themen 9
P Javac ein wirklich nerviges Thema Allgemeine Java-Themen 10
M Suche Java-Projekt zum Thema Elektrotechnik Allgemeine Java-Themen 6
reibi Workspace schon geöffnet (Kein Eclipse Thema) Allgemeine Java-Themen 14
O Feeds zum Thema Java Allgemeine Java-Themen 10
ARadauer allgemeines zum thema java security Allgemeine Java-Themen 5
D Leidiges Thema MVC *g* Allgemeine Java-Themen 2
K Frage zum thema Java und Internet Allgemeine Java-Themen 49
O Fehler in Listing aus Buch ? Thema: Threads und Threadpool Allgemeine Java-Themen 8
G Links zum Thema Synchronisation Allgemeine Java-Themen 7
M -->: Seite war mit Virus infiziert, daher neues Thema . Allgemeine Java-Themen 3
A Thema JAR-Erstellung (mal wieder) => etwas komplizierter Allgemeine Java-Themen 8
P Das leidige Thema: Referenzen Allgemeine Java-Themen 2
Chucky Facharbeit Informatik - Thema? Allgemeine Java-Themen 4
D Gehts praktischer? Thema:Verschiedene Instanzen einer Klasse Allgemeine Java-Themen 3
G geeignetes Thema für Kurzreferat? Allgemeine Java-Themen 3
F Frage zum Thema Reflection Allgemeine Java-Themen 13
P DA Thema ??? Allgemeine Java-Themen 2
U Vererbung?! Allgemeine Java-Themen 15
temi Problem mit Aufrufreihenfolge bei Vererbung Allgemeine Java-Themen 3
MiMa Vererbung und Komposition?? Allgemeine Java-Themen 38
Kirby.exe Vererbung bei Generics Allgemeine Java-Themen 7
L Vererbung Verständnis Probleme Vererbung Allgemeine Java-Themen 2
W Generics + Vererbung Allgemeine Java-Themen 47
M Vererbung mithilfe von Bluej Allgemeine Java-Themen 3
M List -Tableview-Javafx-Vererbung Allgemeine Java-Themen 35
A Vererbung Selbstreferenzparameter Allgemeine Java-Themen 14
D Frage zu Vererbung Allgemeine Java-Themen 5
N Vererbung mit GUI Allgemeine Java-Themen 9
E Vererbung Countable mit Vererbung Allgemeine Java-Themen 6
J 2 Fragen zur Vererbung Allgemeine Java-Themen 5
T Javaklassen und vererbung Allgemeine Java-Themen 32
F Vererbung Allgemeine Java-Themen 5
Neumi5694 Vererbung Restriktive Vererbung Allgemeine Java-Themen 4
A Vererbung Übungsaufgabe Vererbung - Erstellung Klassenhierarchie Allgemeine Java-Themen 1
J Allgemeine Fragen zu Vererbung Allgemeine Java-Themen 1
kaoZ Generics und Vererbung Allgemeine Java-Themen 3
D Problem bei Vererbung abstrakter Klassen Allgemeine Java-Themen 6
D Object nach Vererbung mit Class Object überprüfen Allgemeine Java-Themen 4
T Super Klasse Vererbung Problem :/ Allgemeine Java-Themen 10
L Unabhängige Auslieferung bei Vererbung Allgemeine Java-Themen 20
S MVC - Vererbung Allgemeine Java-Themen 4
C Enums und Vererbung Allgemeine Java-Themen 6
F Google Guice + Generics + Vererbung Allgemeine Java-Themen 5
D Unterschied Vererbung und Polymorphie? Allgemeine Java-Themen 4
K Vererbung ohne Basisklasse zu kennen Allgemeine Java-Themen 20
Da_Tebe ArrayList<xyz> Verschachtelung oder Vererbung? Allgemeine Java-Themen 6
faetzminator statische Variablen in Interface - Vererbung? Allgemeine Java-Themen 9
M OOP PropertyChangeListener - Vererbung oder Komposition? Allgemeine Java-Themen 5
S OOP Mehrfache Vererbung von abstrakten Klassen Allgemeine Java-Themen 7
G Designfrage Vererbung ja oder nein Allgemeine Java-Themen 9
S equals - Identität ändern bei Vererbung? Allgemeine Java-Themen 5
dayaftereh Vererbung Hilfe Allgemeine Java-Themen 2
D Vererbung, Reflection und automatischer Methodenaufruf Allgemeine Java-Themen 24
A PropertyChangeListener Vererbung Allgemeine Java-Themen 4
P DefaultTreeCellRenderer Vererbung Allgemeine Java-Themen 5
S Objekte die Objekte enthalten: Keine Vererbung Allgemeine Java-Themen 4
J Vererbung bei abstrakten Klassen Allgemeine Java-Themen 2
S Vererbung: Welche Methode wird verwendet? Allgemeine Java-Themen 9
L Checkstyle: Wann ist eine Methode für Vererbung entworfen? Allgemeine Java-Themen 13
S normale vererbung als interface Allgemeine Java-Themen 2
S statische Methoden und Vererbung Allgemeine Java-Themen 6
R Vererbung - doppelte Paint-Methode Allgemeine Java-Themen 4
R Vererbung mit Interface und Abstract Allgemeine Java-Themen 3
B Vererbung bei enums ? Allgemeine Java-Themen 3
W Frage zu Vererbung / konkretes Beispiel Allgemeine Java-Themen 4
F Vererbung von SessionBeans Allgemeine Java-Themen 3
O abstract, privat, Vererbung Allgemeine Java-Themen 29
L Annotations mit Vererbung Allgemeine Java-Themen 4
M Singleton und Vererbung? Allgemeine Java-Themen 45
T Problem mit Vererbung Allgemeine Java-Themen 3
V Vererbung und Schleifen Allgemeine Java-Themen 5
C Comparable + Vererbung Funktioniert nicht? Allgemeine Java-Themen 4
A Ansatz Objektorientierung, Methoden Vererbung Allgemeine Java-Themen 2
D Listen von Generischen Typen inkl. Vererbung Allgemeine Java-Themen 2
D Zugriffsmethode nach Vererbung ändern? Allgemeine Java-Themen 5
S Vererbung in UML Allgemeine Java-Themen 3
T Nochmal Frage zu Vererbung Interfaces etc. Allgemeine Java-Themen 10
Y Gedanken zur Vererbung Allgemeine Java-Themen 7
F Vererbung, Generizität und Collections. Allgemeine Java-Themen 7
G Frage zu statischen Variablen bei Vererbung Allgemeine Java-Themen 15
F Vererbung Allgemeine Java-Themen 5
S Vererbung von mehreren Klassen? Allgemeine Java-Themen 5
C enum und Vererbung Allgemeine Java-Themen 3
K Problem mit Vererbung - Kein wirklicher Nutzen. Allgemeine Java-Themen 10
G vererbung vs benutzung Allgemeine Java-Themen 7
L Vererbung klappt nicht Allgemeine Java-Themen 5
W Probleme mit Arrays und Vererbung ! Allgemeine Java-Themen 5
M vererbung einer "selbst-instanzierungs-klasse" Allgemeine Java-Themen 16
J Vererbung. Allgemeine Java-Themen 8
H Frage zur Vererbung Allgemeine Java-Themen 5
S private Instanzvaribalen bei "Innerer-Vererbung" Allgemeine Java-Themen 9
H Vererbung auch ohne erzeugung einer Instanz möglich? Allgemeine Java-Themen 3
M frage zur vererbung Allgemeine Java-Themen 12
G Generics und Vererbung. Allgemeine Java-Themen 21
M Vererbung von Hashtables Allgemeine Java-Themen 5

Ähnliche Java Themen

Neue Themen


Oben