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.
Geht es darum das die lokale Variable "person" vom Typ "Person" ist aber direkt mit einem "Mann" Objekt initialisiert wird?
Es ist zwar richtig und möglich es so zu schreiben, Sinn sehe ich da aber auch keinen dahinter.
Wenn ich weiß das es nur ein "Mann" Objekt sein kann, dann kann die Variable auch gleich vom Typ "Mann" sein.
Sprich wenn man weiß mit welche konkrete Klasse man verwendet, dann kann die Variable auch vom entsprechenden Typ sein.
... dann ist es doch sehrwohl relevant, ob ich:
Person a = new Mann(); oder Mann a = new Mann(); schreibe - oder? Hier wird dann die jeweilige print Methode aufgerufen.
ersteres gibt PERSON ..... aus und zweiteres MANN ....
weil, erst zur Laufzeit dann gecheckt wird, dass a eigentlich ein Objekt vom Typ Mann ist, und nicht von Person. (Latebinding)
Zumindest habe ich dies so zu hören bekommen, gerne lasse ich mich eines anderen belehren. Dass Person a = new Mann() aber ein Quatsch ist, so wie es zunächst im anderen Thread geschrieben wurde ist nicht korrekt - das ist gültiger Code und macht auch Sinn, da Mann eine Unterklasse von Person ist, dementsprechend ist es auch korrekter Code.
Zeile 14 wird so nicht funktionieren. Da fehlt ein new.
Aber das ist glaube ich nicht die eigentliche Frage.
Es macht durchaus Sinn eine Variable eines Basistyps zu definieren und mit einem speziellen Typ zu initialisieren.
Damit gibt man beispielsweise dem Compiler bekannt, dass man nur Methoden, die in der Basisklasse implementiert sind, benutzen möchte.
Ein Beispiel, wo man noch einen Schritt weitergeht, sind Interfaces.
Wenn ich eine Liste verwende, schreibe ich:
Java:
List<String> myList = new ArrayList<String>();
List ist dabei nicht einmal die Basisklasse, sondern "nur" das Interface. ArrayList hingegen ist die konkrete Implementierung.
Bei Methoden, die "myList" als Parameter bekommen, ist der Parameter ebenfalls ein List<> Typ.
Wenn ich später dann draufkomme, dass LinkedList<> eine bessere Implementierung wäre, kann ich dass beim Erstellen des Objekts ändern und alles andere bleibt gleich.
Die Vorteile dieses Patterns sind bei kleinen Programmen allerdings nicht so leicht darstellbar. Erst wenn man viele Klassen hat und sich eine Änderung durch einen großen Teil davon durchzieht, lernt man das zu schätzen.
Es macht durchaus Sinn eine Variable eines Basistyps zu definieren und mit einem speziellen Typ zu initialisieren.
Damit gibt man beispielsweise dem Compiler bekannt, dass man nur Methoden, die in der Basisklasse implementiert sind, benutzen möchte.
machst kommst du nur an die Methoden die in der Person-Klasse sind.
In dem Fall wurde aber explizit ein Objekt vom Typ Mann benutzt, da dieser ja die Größe um 5 erhöhen wollte ( und da wurde die Methode in der Mann Klasse überschrieben ) .
Wenn du nur
Java:
Person person = new Person();
machst wird die "allgemeine" Methode getGroesse aufgerufen, und nicht die speziellere,gewünschte Methode von Mann.
Das ist einfach nur Vererbung. Wenn eine Klasse eine Methode einer Oberklasse übertschreibt, dann wird auch diese ausgeführt. Auch wenn das Objekt in einer Variablen vom Typ der Oberklasse steckt.
Mann/Frau können jetzt alle Methoden von Person selber implementerien und überschreiben
(@Override). Wenn man die "alten" Methoden (also von Person) trotzdem noch verwenden
will, kann man mit super.methode() immer noch explizit darauf zugreifen.
Mann/Frau können jetzt alle Methoden von Person selber implementerien und überschreiben
(@Override). Wenn man die "alten" Methoden (also von Person) trotzdem noch verwenden
will, kann man mit super.methode() immer noch explizit darauf zugreifen.
Das ist echt ein witziges Beispiel. Weil Java an dieser Krücke der strikten Typisierung krankt, muss man sowas machen um die in ein Array zu bekommen. Jetzt weis ich wieder warum ich C so liebe.
??? Das ist ganz normal. Das macht man so...
Das gleiche mit Interfaces...
Java:
List<String> list = new ArrayList<String>();
list.add("Test");
Welche add Methode wird hier aufgerufen? die von List oder ArrayList? Die von ArrayList natürlich. List hat ja nicht mal eine Implemtierung... Auch wenn List eine Klasse wäre, wäre es das gleiche Verhalten...
gehört gesteinigt? Das finde ich in dem 700k LOC Projekt, an dem ich garade arbeite, tausendfach..
Das ist echt ein witziges Beispiel. Weil Java an dieser Krücke der strikten Typisierung krankt, muss man sowas machen um die in ein Array zu bekommen. Jetzt weis ich wieder warum ich C so liebe.
Bitte was?! Ich kriege in dynamisch typisierten Sprachen regelmäßig das kalte Kotzen wegen sowas; beispiel PHP:
PHP:
class Person
{
}
class Mann extends Person
{
public function getSize() {...}
}
class Frau extends Person
{
public function getAge() { ... }
}
// ich habe da ne liste an personen. das sind aber erstmal alles männer
$personen = [new Mann(), new Mann()];
// jetzt meint irgendein trottel "och, frau ist ja auch eine person"
// und $personen sieht auf einmal so aus:
$personen = [new Mann(), new Frau(), new Mann()];
// irgendwo anders im Code mache ich (weil ich ja weiss, dass alle personen Männer sein sollten)
$personen[$x]->getSize();
// und BUMM! Fatal Error: Call to undefined method getSize() ...
// HTTP 500 Fehler, komplette Seite ist gecrashed
Wenn ich Java jetzt aber deklariere, dass personen ein Mann[] ist, weisst der Compiler freundlich darauf hin, dass da keine Frau reinpasst. Bzw, wenn das Personen sein sollen, das aber vorläufig nur Männer sind, schreibe ich eben:
Java:
Person[] personen = new Person[] { new Mann(), new Mann() };
Und wenn ich dann personen[x].getSize() aufrufe, weisst mich auch schon der Compiler darauf hin, dass das nicht geht.
Und ich verrate euch auch, warum ich dynamisch typisierte Sprachen hasse und statisch typisierte liebe (wers nicht eh schon erraten hat): Meine Java-Anwendung scheitert nicht an derart simplen, peinlichen und absolut vermiedbaren Problemen, weil Java statisch typisiert ist.
@Thallius: Zu "wer Person p = new Mann() macht gehört gesteinig" fällt mir nur ein: warte nur ab, bis du das mal auf dem schmerzhaften Weg lernst. Warte nur ab und loes diesen Thread dann nochmal. Ich hoffe du stirbst dann selbst vor Scham über diesen Stuss, den hier gerade von dir gibst.
Sorry Tobse bisher dachte ich immer du bist einer der Guten hier. Aber ein Ton den du hier anschlägst ist echt nicht angebracht.
Ich programmiere schon seit über 30 Jahren professionell und ich kann dir sagen. Ich habe es noch nie geschafft "aus Versehen" eine falsche Variable in eine Collection zu stecken.
Wahrscheinlich bin ich einfach zu gut oder was?
Im Endeffekt ist es egal ob man statisch oder dynamisch typisierte Sprachen benutzt wenn man vorher ein vernünftiges Konzept erstellt.
Ich komme damit deutlich besser klar das ich zwei verschiedene Klassen in einem Array habe als das ich gleiche Klassen habe die in wirklichkeit gar nicht gleich sind. Das ist doch total verwirrend...
Ich programmiere schon seit über 30 Jahren professionell und ich kann dir sagen. Ich habe es noch nie geschafft "aus Versehen" eine falsche Variable in eine Collection zu stecken.
Wahrscheinlich bin ich einfach zu gut oder was?
Doch, vielleicht bist du das. Du glaubst ja garnicht, was für schrottiger Code zum Teil in der freien Wildbahn unterwegs ist, und auchnoch produktiv eingesetzt wird. Schau dir nur mal die ganze PHP Freeware an die zuhauf verwendet wird. Da kriegt man Haare auf den Zehen.
Ich programmiere jetzt auch schon eine Weile (wenn auch noch keine 30 Jahre...) mit statisch und dynamisch typisierten Sprachen. Wenn ich eine Methode deklariere
PHP:
/**
* @param Mann[] personen Muss ein Mann[] sein!
*/
function doSomething(array $personen) {...}
Dann kann ich davon ausgehen, dass jeder halbwegs vernünftig denkende Programmierer nicht auf die Idee kommen, ein Frau-Objekt in das array zu stecken.
Aber ich habe auch schon mit Codebasen von mehreren tausend Klassen gearbeitet. Da kommt es schon mal vor, dass man sowas vergisst; evtl. weil die Namensgebung der Methode nicht ganz eindeutig ist oder weil gerade die Deadline drückt und man mit dem Kopf an einem ganz anderen Problem ist.
Und schon ist eben doch einem von 100 Fällen ein Frau-Objekt im Array, das eigentlich nur Männer beinhalten dürfte. Und dann fliegt einem das Teil beim Kunden um die Ohren, geil!
In Java weisst mich schon die IDE beim schreiben des Codes darauf hin, dass das nicht geht (es sei denn, ich trickse sie mit ein paar casts aus; in diesem Fall bin ich dann aber wirklich selbst Schuld).
Ich komme damit deutlich besser klar das ich zwei verschiedene Klassen in einem Array habe als das ich gleiche Klassen habe die in wirklichkeit gar nicht gleich sind. Das ist doch total verwirrend...
Du verstehst da was falsch. Es ist ein Array mit verschiedenen Objekten. Du Deklarierst aber eine übergeordnete Klasse, weil es egal ist, ob das eine Mann oder eine Frau ist. Wenn du nur Mann-Objekte haben willst, dann musst du das halt deklarieren (ist ja nicht das Problem).
Wenn du jetzt eine Klasse Person definierst:
Java:
abstract class Person
{
/**
* Gibt die Größe der Person in Metern zurück.
*/
public float getSize();
}
Und jemand anders (oder du 3 Monate später) implementiert dann Mann extends Person und meint dabei "Männer geben ihre Größe aber in Centimetern an" dann ist das nicht etwa "Freiheit" oder "Dynamik" sondern schlicht Schwachsinn.
Das sind absolute Grundprinzipien von OOP. Wenn Dir die nicht gefallen, bist du in der C-Welt wahrscheinlich besser aufgehoben.
Angenommen du hast die Klasse Fahrzeug. Von Fahrzeug erbt PKW und Motorrad. Du willst eine Klasse Fähre schreiben. In Java nimmt man dafür dann Fahrzeug, weil das der kleinste gemeinsame Nenner zwischen allen Objects ist, die du transportieren möchtest.
Wie würden denn dein Konstruktor für die Klasse Fähre aussehen, Thallius? (Und ich meine diese Frage 100% ernst, ich glaube hier besteht ein sehr großes Missverständnis).
Ich verstehe gerade nicht worauf du hinaus willst.
Mir geht es einzig und alleine darum, dass ich es für total verwirrend halte eine Variable als Person zu deklarieren, ihr aber in Wirklichkeit ein Objekt der Klasse Mann zuzuweisen. Und wenn ich dann diese Person an eine andere Methode weitergebe und die dann eine Methode davon aufruft, dann benutzt diese aber in Wirklichkeit die methodecvon Mann?
Also
Java:
public static main ()
{
Person person = new Mann()
this.macheIrgendwasMitEinerPerson(person);
}
private machrIrgendwasMitEinerPerson (Person person)
{
int groessen=person.getGroesse(); // hör bekomme ich jetzt die Größe+5 weil Person eigentlich ein Mann ist, ich weis in der Methode aber gar nichts davon. Das ist doch vollkommen verwirrend.
}
@Thallius: Ich habe dir eine PN geschickt, um dich auf deine meiner Meinung nach falsche Aussage aufmerksam zu machen - Nun stellst du es ins Forum und erwartest von anderen Usern eine Meinung, erhaltest diese von MEHREREN Usern ( nicht nur von mir ) aber akzeptierst sie immer noch nicht.
Das ist eine Grundlage in der OOP in Java - wenn du schon 30! Jahre programmierst, frage ich mich was du programmierst?
Kann doch nicht sein dass du nach einer 30 jährigen Erfahrung dieses Konzept dir nicht erklären lässt, außerdem sagst du eiskalt das ist "kompletter Müll". Für den ersten Moment passt das auch (passiert bestimmt jedem^^), aber wenn's dir 10 Leute näherbringe möchten und eigentlich alle vom selben schreiben müsstest du doch einmal das Zeug schlucken, nicht?
Sorry aber Bitte beteilige dich doch mal mit Argumenten an der Diskussion. Und nur weil es in Java anscheinend der Weg ist den alle nutzen muss es doch nicht das non plus ultra der Programmierung sein. Da solltest du mal ein wenig über den Tellerrand dieser Programmiersprache hinaus sehen. Und das zu diskutieren sollte erlaubt sein auch wenn es für mich natürlich schwer wird in einem Java Forum gegen die Sprache zu argumentieren.
Mehr kann ich dazu leider nicht sagen, dass ist das mit dem ich Erfahrung gemacht habe. Ich programmiere leider noch keine 3,4,5,6,7,8,9,10 Jahre in Java , deswegen ist es an dieser Stelle besser wenn User in einem höheren Stadion eine Meinung von sich geben, was eigentlich schon geschehen ist.
Das ganze Konzept dahinter nennt sich Information Hiding und ist eines der Grundkonzete der Objektorientierung. Wenn du die Größe einer Person benötigst, dann erhältst du auch die Größe der konkreten Person auf die deine Variable verweist. Und die Größe ist in dem Fall bei Männern so definiert, dass sie um 5 größer ist als bei der Standarddefinition. Wichtig ist dabei nur das das Objekt seinen Vertrag erfüllt und seine korrekte Größe zurückliefert.
Wie es das macht sollte für den Nutzer des Objektes völlig transparent sein. Du kannst jetzt beispielsweise deine Personenliste durchgehen und die Durchschnittsgröße ermitteln. Ob es sich dabei nun um Kinder Männer oder Frauen handelt ist für den Anwendungszweck völlig irrelevant. Sollte es in 10 Jahren nötig sein das Programm um ein neues Geschlecht zu erweitern wird deine Methode immer noch korrekt funktionieren weil du sauber gearbeitet hast indem du von der Implementierung abstrahiert hast. Und genau das ist der Vorteil.
Erstmal das ist nicht nur bei Java so, sondern auch bei C#, Python, etc.
Ich glaube ein gutes Beispiel zur Verdeutlichung dürften UI Elemente sein.
Ein UI Framework hat keine Ahnung davon was ein Button, Textbox, etc ist. Da Benutzer auch neue Komponenten erfinden können, macht es natürlich auch keinen sinn für jede mögliche Komponente eine neue Liste anzulegen.
Stattdessen hat man eben eine Liste vom Typ Component (und Button, etc. erben halt davon).
Wenn nun alles gezeichnet werden soll, wird eben die Liste durchgegangen und imemr nur die paint Methode aufgerufen, ob dahinter nun ne Textbox oder ein Button steckt ist ja egal, die zeichnen sich ja schön selbst.
Und genau hier ist eben klar, dass eben nicht immer zwingend die paint-Methode der Component klasse aufgerufen werden soll, sondern (wenn vorhanden) eben die jeweilige Methode der Buttons, etc.
Ich hoffe mal dass das Beispiel hilfreich ist, ansonsten kann ich mich meinen vorrednern eigentlich nur anschließen.
In meinem 1.Post habe ich gemeint das für mich diese Codezeile keinen Sinn macht, und dabei bleibe ich auch.
Weil es bei diesem konkreten Beispiel wirklich keinen Sinn für mich macht
Mir geht es einzig und alleine darum, dass ich es für total verwirrend halte eine Variable als Person zu deklarieren, ihr aber in Wirklichkeit ein Objekt der Klasse Mann zuzuweisen. Und wenn ich dann diese Person an eine andere Methode weitergebe und die dann eine Methode davon aufruft, dann benutzt diese aber in Wirklichkeit die methodecvon Mann?
Ja es wird die Methode des Objektes aufgerufen nicht die Methode der Klasse!
Jemand der mit den entsprechenden Sprachen "aufgewachsen" ist und nicht mit C wird damit keine Probleme haben.
private machrIrgendwasMitEinerPerson (Person person)
{
int groessen=person.getGroesse(); // hör bekomme ich jetzt die Größe+5 weil Person eigentlich ein Mann ist, ich weis in der Methode aber gar nichts davon. Das ist doch vollkommen verwirrend.
}
Zu diesem Beispiel: Es ist doch vollkommen egal ob hinter dem Objekt "person" nun eigentlich ein Mann, eine Frau oder sonst etwas steckt. In der Methode willst du mit der Größe der Person arbeiten und dabei kann es dem Programmierer egal sein ob es sich um einen Mann oder eine Frau (oder sonstwas) handelt. Mit "getGroesse()" bekommt er die Größe
Und nennst polymorphismus und dynamische bindung "total krank"?
Nicht böse gemeint ;-)
Man muss sich einfach überlegen, warum ich Vererbung mache... zb bei Rich Client GUI Programmierung... es ist doch sinnvoll das ein Container eine Liste von Kind Elementen beinhaltet die evtl von einer Abstrakten Klasse ableiten.
Also ich hab einen Dialog, der einen Button und ein Textfeld vom Typ Drawable beinhaltet. Wenn jetzt irgendwo auf diese Drawables die Methode draw aufgerufen wird, dann müssen die spezifischen Methoden vom Button und Textfeld aufgerufen werden. fertig.. deshalb mache ich das.
Das ist doch einer der Hauptgründe von Vererbung. Oftmals wird vererbung zur wiederverwendung von Code eingesetzt, was ich allgemein bei komplexeren Sytemen als nicht hilfreich entfinde, da hier Komposition praktischer ist.
Mir geht es einzig und alleine darum, dass ich es für total verwirrend halte eine Variable als Person zu deklarieren, ihr aber in Wirklichkeit ein Objekt der Klasse Mann zuzuweisen. Und wenn ich dann diese Person an eine andere Methode weitergebe und die dann eine Methode davon aufruft, dann benutzt diese aber in Wirklichkeit die methodecvon Mann?
Ich würde mal Head First on Design Patterns lesen... bzw die ersten paar Kapitel.
Man schreibt ja Tools, Services, Apis, die eher mit allgemeinen Klassen umgehen können.
Man hat nicht ArrayList als Parameter in seiner Methode sonder was allgemeineres wie List... Collection finde ich schon wieder übertrieben ;-)
Deshalb mach es auf jeden Fall Sinn, einen Mann als Person zu verwenden...
Ich muss mich auch nochmals allen hier anschließen. Es gehört einfach zu OOP (und nicht zu Java). Jede Sprache mit Objektorientierung macht das so. Ob es nun das non plus ultra ist, ist damit nicht bewiesen. Aber die Erfahrung hat gezeigt, dass es besser funkktioniert als der prozeduale Ansatz.
Ich denke, das wurde hier jetzt auch schon oft genug und mit ausreichender Anzahl an Beispielen dargestellt.
:rtfm:
