Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
ich bin dabei mir ein 2D-Spiel zu programmieren.
Nun möchte ich eine Klasse (Klassenname: "Physik") erstellen, in der Methoden - wie fallen(),springen() - vorkommen, die nicht nur auf den Spieler, sondern auch auf den Gegner anwendbar sein soll.
Nun möchte ich wissen, welche Klasse welche kennen muss und welche ein Objekt davon haben sollte.
Vlt. versteht ihr was ich meine und könnt ihr mir ja weiter helfen.
Kommt immer darauf an, was für ein Spiel du machst. Ich glaube, es wäre generell besser, wenn du z.B. eine Klasse "Lebewesen", welche die Methoden beinhaltet, erstellst und davon den Spieler sowie die Gegner ableitest.
ich habe gerade nochmal überlegt und ich möchte gerne auch noch objekte (z.B.: Würfel) einbauen, die dann auch die klasse brauchen, in der das mit dem das fallen, durch meine erdanziehungskraft steht.
oder kann/sollte ich ein objekt von physik erstellen, welches ich über meine hauptklasse an spieler,gegner,wuerfel weitergebe? oder wäre das nicht so effektiv?
denn immerhin muss der spieler ja die physik kennen, um sie anzuwenden
So wie du das beschreibst, würde ich eher ein Inteface "Physik" machen. extends = "is-a"-Beziehung implements = "behaves-like"-Beziehung
So als Faustregel.
so... habe mich mal "kurz" etwas in interface eingelesen. ein interface hätte für mich jetzt hier ja keinen sinn. alle objekte sollen ja den gleichen methoden-body haben,...ohne... das ich in jeder klasse jedesmal etwas ändern muss.
und extenden wäre hier auch für mich sinnfrei, da man nur eine klasse erben lassen kann.
wäre es dann sinnvoll hier ein objekt der klasse "Physik", mit den methoden (fallen,springen,usw.) an Spieler,Gegner,Wuerfel zu übergeben?
Das ist nicht richtig, du kannst eine Klasse nur von einer anderen ableiten. Eine Superklasse kann jedoch mehrere Subklassen haben.
Ich würde eine Klasse "BasisObjekt" erstellen, die die Methoden springen, laufen und weitere hat. Von dieser würde ich dann sowohl Gegner und Spieler als auch andere Objekte ableiten.
ich hatte jetzt vor: ein objekt der klasse "physik" zu erstellen und dem übergebe ich dann spieler und welt.
die physik sorgt dann für die schwerkraft und so...
ist ja wie in echt. die physik kennt ja "alles" und kann sie darauf anwenden. der echte mensch muss ja nicht die physik kennen, um fallen zu können.
wäre dies dann auch eine akzeptable und sinnvolle lösung?
Funktionieren tut das warscheinlich. Aber das ist viel umständlicher. Warum lässt du die Physik all das machen, wenn der Spieler es auch selbst tun kann? Ich denke, dass Vererbung hier angebrachter ist.
ich will die physik ja nicht nur auf den spieler anwenden, sondern später auch auf gegner und fallende objekte.
soll ich also bestens den spieler von physik extenden lassen?
Inerface erstellen welches die Methoden bereitstellt, abstrackte Basisklasse erstellen welche die Grundform alles sich z.B bewegenden Objekte darstellt, und diese klasse Implementiert dann das Interface.....
Beispiel anhand eines bewegbaren Objektes:
Java:
public interface Moveable{
void move();
}
Java:
abstract class Entity implements Moveable{
@Override
public void move(){
// do some moving stuff right here.... or do noting ( hook )
}
}
du kannst dann auch einfach sagen du implementierst in der Basisklasse garkeine funktionalität (hook) und oder du implementierst die Methode dort erst garnicht , so sorgst du dafür das jede Konkrete Klasse dann ihre eigene Implementierung liefern muss.
Beispiel :
Java:
class Player extends Entity{
@Override
public void move(){
if(left){
x--;
}
else if(right){
x++;
}
}
}
da die Basisklasse hier nun schon das interface implementiert, und die Klasse Player diese erweitert, hat der Player eben vollen zugriff auf die Methoden und Felder ( je nach Zugriffsmodifizierer ) der Elternklasse.
du solltest dich einfach mal voher hinsetzen und schauen wo du welche Abhängigkeiten erzeugen musst, bzw. wo du diese eben vermeiden solltest,
es gibt z.B bewegliche Blöcke die eben nicht Spielbar sind, hier könnte man dann wieder zwischen verschiedenen Spezialisierungen unterscheiden. MoveableEntity's oder auch PlayableCharacters, NPC's usw. usw.
ich will die physik ja nicht nur auf den spieler anwenden, sondern später auch auf gegner und fallende objekte.
Das was du da vorhast ist keine Spieleprogrammierung sondern eher eine Engine, welche sich letzen endes um all diese Dinge kümmert, wie z.B fallen , laufen , springen usw. usw. und dieses ist um einiges komplizierter als erstmal herzugenen und zu sagen das jeweilige Objekt ist selbst für seinen Zustand verantwortlich , im Falle eines Spielers wäre das dann z.B das Springen , der Spieler springt, wie er springt weiß nur der Spieler selbst.
Zum einen sorgt es dafür das du keine direkten Instanzen dieser Klasse erstellen kannst. ( Anonyme außen vorgenommen )
Zum anderen legst du hier schon fest das es eben eine Abstrakte Definition von irgendetwas gibt.
welchen sinn macht eine abstrakte klasse überhaupt?
Du hast hier die Möglichkeit Gemeinsamheiten zu definieren, und ggf. existierende Grundfunktionen zur Verfügung zu stellen.
Deshalb habe ich auch Entity als Klassennamen gewählt , sinnbildlich übersetzt steht dieser Begriff im Deutschen nämlich für Ding
Also eine Abstrakte Umschreibung für irgendetwas von dem hier zu dem Zeitpunkt noch keine Definition vorliegt.
Somit könnte eine Entität alles sein , wozu du sie machst, ein Auto , ein Mensch, ein Spieler usw.
Dies hängt dann später von dem Aufbau deiner Vererbungshierarchie und der Implementierung eventueller Interfaces ab.
Somit kannst du eventuelle Funktionalitäten, und oder Attribute ( Member / Instanzvariablen ) bereits definieren auf die dann alle Unterklassen, also Spezialisierungen Zugang erhalten.Man Spricht hier auch von Generalisierung, also wenn du versuchst eine Konkrete Gegebenheit, weiter zu Abstrahieren, du solltest dir dazu wie Joose schon erwähnt hat mal den ein oder anderen Artikel durchlesen.
nochmal zu bestätigung frage ich mal ob das so richtig ist:
das interface gibt vor, welche methoden es gibt, die man im player implementier.
die abstrakte klasse "entity" legt weitere methoden fest, die man übernehmen/erben kann.
und der player kann dann die methoden abändern.
Abstrakte Klassen können abstrakte Methoden beinhalten, diese abstrakten Methoden sind nicht implementiert.
Diese abstrakte Methoden müssen in der Subklasse mit einer konkreten Implementierung überschrieben werden.
(alle anderen Methoden können, müssen aber nicht überschrieben werden, normales Override)
Fazit: Ein Interface und eine abstrakte Klasse ZWINGEN dich dazu vorgegeben Methoden zu implementieren.
Der Unterschied zwischen den beiden ist das eine abstrakte Klasse wie eine normale Klasse Attribute und Methode enthalten kann, welche eine Basisfunktionalität bereitstellen.
