Diskussion:Java Standard: Vererbung
Aber hallo!!!
BearbeitenSind Änderungen nur um die Klammersetzung von hinten in die nächste Zeile zu setzen wirklich der Weisheit letzter Schluss? Abgesehen davon, dass ich die Klammern hinten mag würde ich mich über mehr quantitative Beiträge freuen. Leicht verärgert: Bastie
- Also grundsätzlich finde ich solche Änderungen auf keinen Fall übertrieben, denn schließlich ist das einheitliche und "runde" Aussehen des Buches ja auch wichtig. Allerdings finde ich die konkreten Änderungen in diesem Fall auch unangebracht, weil wir uns bisher ja noch gar nicht auf einen einheitlichen Stil einigen konnten. --Underdog 00:06, 22. Apr 2005 (UTC)
Habe mal "Interfaces" rausgenommen. Gibts andere Meinungen?--Aler 16:10, 28. Mär 2005
Das Private nicht vererbt wird ist nicht ganz richtig. Ich habe nur keine Ahnung wie man es am besten ausdrückt, (Nebenbei packagevisible fehlt noch). Private deklarierte Felder werden durchaus vererbt lediglich der Zugriff auf diese ist verwehrt. Hat vielleicht einer einen schönen Satz dazu? --Bastie 18:51, 21. Mär 2005 (UTC)
- wo wird denn packagevisible eingeordnet? gleiche hierachieebene wie public, usw. ?--Aler 9:55, 22. Mär 2005 (UTC)
- Was meinst Du denn mit "Hierarchieebene"? Also von der Bedeutung her entspricht die package-Sichtbarkeit am ehesten dem Schlüsselwort protected. Bei package-Sichtbarkeit können nur Klassen aus dem selben package auf das Element zugreifen, während mit "protected" zudem auch Subklassen aus anderen packages Zugriff haben. --Underdog 02:50, 23. Mär 2005 (UTC)
- mit hierarchieebene meine ich die einordnung ins inhaltsverzeichnis. also (im wiki-stil geschrieben) eine Überschrift mit einem = ist hierarchieebene 1, mit == ist ebene 2, usw.--Aler 19:00, 26. Mär 2005
- dann setze ich mal packagevisible mit rein - mit deinem text, underdog? ich find den nämlich ganz gut zur erklärung ...--Aler 20:00, 26. Mär 2005
- Achso, jetzt verstehe ich. Ja, packagevisible gehört von seiner Bedeutung auf jeden Fall auf die selbe Ebene wie public, protected und private. Allerdings ist die Beschreibung von mir hier nicht so gut zu gebrauchen, würde ich sagen - weil das mit Vererbung eigentlich nicht so viel zu tun hat. Die Sichtbarkeitsbedeutungen der verschiedenen Modifizierer werden übrigens ohnehin bereits unter Java Standard: Schlüsselwörter beschrieben (Auch wenn sich an dieser Struktur wohl noch was ändern wird). Wie Bastie schon richtig geschrieben hat, stimmt es ja auch nicht, dass private Elemente nicht vererbt werden - und generell haben private, protected etc. mit Vererbung nicht so viel zu tun, sondern mit Zugreifbarkeit. Im Zusammenhang mit Vererbung wäre es imo daher viel wichtiger, auf Modifizierer wie static, abstract etc. einzugehen. Die Sichtbarkeitsmodifizierer würde ich hier insgesamt nur kurz erwähnen, da sie hinsichtlich der Vererbung kaum mehr tun können als ein bestimmtes Verhalten in Unterklassen zu erzwingen (so kann z.B. die Sichtbarkeit einer überschriebenen Methode in einer Unterklasse ja nicht restriktiver definiert werden als die der Oberklasse). --Underdog 23:16, 26. Mär 2005 (UTC)
- Die Modifizierer erwähne ich hier, weil Anfänger damit Probleme haben. Zumindestens habe ich es so in Erinnerung. Aber länger als schon geschehen wollte ich es eh nicht schreiben.--Aler 11:00, 28. Mär 2005
- Achso, jetzt verstehe ich. Ja, packagevisible gehört von seiner Bedeutung auf jeden Fall auf die selbe Ebene wie public, protected und private. Allerdings ist die Beschreibung von mir hier nicht so gut zu gebrauchen, würde ich sagen - weil das mit Vererbung eigentlich nicht so viel zu tun hat. Die Sichtbarkeitsbedeutungen der verschiedenen Modifizierer werden übrigens ohnehin bereits unter Java Standard: Schlüsselwörter beschrieben (Auch wenn sich an dieser Struktur wohl noch was ändern wird). Wie Bastie schon richtig geschrieben hat, stimmt es ja auch nicht, dass private Elemente nicht vererbt werden - und generell haben private, protected etc. mit Vererbung nicht so viel zu tun, sondern mit Zugreifbarkeit. Im Zusammenhang mit Vererbung wäre es imo daher viel wichtiger, auf Modifizierer wie static, abstract etc. einzugehen. Die Sichtbarkeitsmodifizierer würde ich hier insgesamt nur kurz erwähnen, da sie hinsichtlich der Vererbung kaum mehr tun können als ein bestimmtes Verhalten in Unterklassen zu erzwingen (so kann z.B. die Sichtbarkeit einer überschriebenen Methode in einer Unterklasse ja nicht restriktiver definiert werden als die der Oberklasse). --Underdog 23:16, 26. Mär 2005 (UTC)
- Was meinst Du denn mit "Hierarchieebene"? Also von der Bedeutung her entspricht die package-Sichtbarkeit am ehesten dem Schlüsselwort protected. Bei package-Sichtbarkeit können nur Klassen aus dem selben package auf das Element zugreifen, während mit "protected" zudem auch Subklassen aus anderen packages Zugriff haben. --Underdog 02:50, 23. Mär 2005 (UTC)
Kommentar zu abstract
BearbeitenSorry, bin noch neu hier und z.Zt. noch anonym eingeloggt. Ich wollte aber darauf hinweisen, dass "Damit wird also zugesichert, dass jedes Objekt des Typs BeispielKlasse - und damit auch jedes Objekt einer davon abgeleiteten Klasse - die Methode schreibIrgendwas() besitzen muss." IMHO nicht ganz korrekt ist. Wie schon im Orginaltext erwähnt kann es nie Objekte von BeispielKlasse geben, da die Klasse abstract ist, Objekte von weiter abgeleiteten Klassen eventuell schon. Wollt ich erstmal anfragen, bevor was ich ändern würde.
- Da hast du natürlich recht. Grundsätzlich darf man hier Änderungen vornehmen ohne nachzufragen - wollte ich nur noch mal erwähnen. -- Daniel B 17:13, 21. Jul 2005 (UTC)
Konstruktoren und Polimorphie
BearbeitenEs sollten Beispiele für bestimmte Konstruktoren gegeben werden. Z.B. wie man Methoden des Standartconstruktor z.B.
irgendwie: class meineKlasse(){ void meineMethode(){Anweisung1;} }
class meineKlasse(int meineZahl){ void meineMethode(){Anweisung2;} } --Mjchael 15:20, 17. Jan 2006 (UTC)
Mehrdeutigkeit der Aussage
BearbeitenFolgende Aussage ist nicht eindeutig:
- "In der Subklasse können Methoden der Basisklasse "überschrieben" werden. Damit wird der Inhalt der ursprünglichen Methode verändert."
Wo fiindet denn die Überschreibung statt, in der Basisklasse oder Subklasse? In der Subklasse können Methoden aus der Basisklasse "überschrieben" werden. Damit wird der Inhalt der ursprünglichen Methode innerhalt der Subklasse verändert. -- 178.25.166.125 11:01, 5. Feb. 2012 (Signatur nachgetragen von: Jürgen 11:52, 5. Feb. 2012 (CET) -- bitte künftig mit 4 Tilden ~~~~ selbst erledigen)
Wie kann man das Überschreiben verhindern?
BearbeitenIMHO besser mit private arbeiten. final protected ist Ansicht schon unglücklich. -- Bastie 19:50, 24. Okt. 2015 (Signatur nachgetragen von: Qwertz84 19:50, 24. Okt. 2015 (CEST)-- bitte signiere deine künftigen Beiträge selbst mit 4 Tilden ~~~~)
IMHO nicht unbedingt. Denke mal, wenn Superklasse von einer Klasse BaseKlasse abgeleitet wurde, die nicht unter deiner Kontrolle ist. Man möchte ab Superklasse Vererbungen von methode() verhindern. Dann bleibt einem nur noch final protected. Ich sehe hier keine Möglichkeit, mit private zu arbeiten. Sollte man diesen Fall ergänzen? Qwertz84 19:50, 24. Okt. 2015 (CEST)