Überladen, Überschreiben, Verstecken, Verschatten

Kann mir jemand Unterschied in Java erklären: Überladen, Überschreiben, Verstecken, Verschatten ??? Im Englischen gibt es Shadowing, ist das gleichzusetzen?

Das lässt sich doch unter den genannten Stichworten gut nachlesen. Was genau verstehst du da nicht?

Moin,

sowas vielleicht ??
https://www.google.de/search?q=+Java+Überladen,+Überschreiben,+Verstecken,+Verschatten&ie=utf-8&oe=utf-8&gws_rd=cr&ei=kByJVYjnK6f8ywOukKagAQ#q=Java+Überladen,+Überschreiben,+Verstecken,+Verschattung
Ich tippe das jetzt nicht alles ab :wink:

Gruß Klaus

Aber kann es jemand in 4 Sätzen oder 5 Sätzen (1 Hauptsatz, 4 Nebensätze) erklären? Was verstehe ich nicht? Überschreiben klar. Überladen klar (funkt Überladen nur in abgeleiteten Klassen?). Verstecken (Versuch, public -> private einzuschränken?) unklar. Verschatten unklar. Es ist kein “Troll”-Thema. Es hat schon etwas mit OOP zu tuen. Auch wenn ich (Thema-)Emoticon Cool gewählt hab.

Moin,

Überschreiben geht nur in abgeleiteten Klassen, Überladen geht (fast) immer, da Du hier ja nur eine weitere Sigantur deklarierst!
Mit Verstecken ist dann wohl „Sichtbarkeit einschränken“ gemeint! So ist eine „private“ Variable etwa nur in der Klasse sichtbar, in der sie deklariert wurde …
Zur „Verschattung“ kann ich so aus dem Stand nix sagen, aber auch da hilft Google :eek:

Unterschiede könntest wohl allenfalls zwischen Überschreiben und Überladen rsp. zwischen Sichtbarkeit einschränken und Verschattung rausarbeiten …

Gruß Klaus

[quote=CyborgBeta]Überladen nur in abgeleiteten Klassen?[/quote]Ja.

[quote=CyborgBeta;119199]Verstecken [/quote]Ist Kontextabhängig. Ich würde diesen Begriff verwenden, wen es generell um die Sichtbarkeit von Attributen/Methoden geht.

[quote=CyborgBeta;119199](Versuch, public -> private einzuschränken?) [/quote]geht nicht. Du kannst die Sichtbarkeit nur erweitern (private ausgenommen), nie Einschränken.

[quote=CyborgBeta;119199]Verschatten unklar.[/quote]class Test{ private Object myTest; private void shadowingTest(){ Object myTest= 'diese lokale Variable Versteckt/Überschattet/shadowed die gleichnamige Member-Variable."; } }

bye
TT

Zu TT’s Post hab ich Widerspruch: Überladen (engl. Overload) heißt, eine Methode gleichen Namens mit anderer Argumentliste zu definieren. Das kann auch in ein und derselben Klasse passieren. Abgeleitete Klassen sind dafür keine Voraussetzung. (vfl_freak hatte es schon richtig).

“Überschreiben” ist übrigens die verunglückte Übersetzung des englischen “Override”

[quote=nillehammer]Zu TT’s Post hab ich Widerspruch: Überladen (engl. Overload) heißt, eine Methode gleichen Namens mit anderer Argumentliste zu definieren.[/quote]Danke für die Berichtigung, ich dachte an Überschreiben.
Im Gegensatz dazu geht Überladen natürlich immer nur innerhalb der selben Klasse…

bye
TT

könnte strenggenommen auch missverständlich sein,
etwa
interface A { public Number get(Number k); }
interface B extends A { public Number get(String k); }
:wink:

[quote=SlaterB]könnte strenggenommen auch missverständlich sein,[/quote]Dem kann ich mich nicht entziehen!
Überladen geht also immer…

bye
TT

Auch wenn CB meint es wäre kein Troll muss ich dennoch den Banhammer rausholen …

@CB
Du sagst dir wären die Begriffe Überschreiben (@Override) und Überladen (methode overload) klar, verdrehst sie aber trotzdem. Wie es richtig rum ist wurde ja bereits mehrfach erleutert.
Zum Verstecken : Wie schon erwähnt wurde ist dieser Begriff vom Kontext abhängig. Wenn du (default/protected/public) -> private meinst, nein, das geht nicht und gibt n schönen Compiler-Error. Wenn damit “Sichtbarkeit von Membern” gemeint ist sollte dir “scope so klein wie möglich” bekannt sein. Oder meinst du damit eine noch andere Bedeutung wie etwa “verstecken der internen Implementierung hinter dem API-Interface” so in Richtung Factory ? Das ist dann noch was ganz anderes. Begriff daher extrem schwammig.
Und zum letzten “Verschattung” würde mir auch nur spontan “shadowing” (wie schon erklärt) einfallen. Daher würde ich spontan die Frage ob Verschattung == shadowing ist erstmal mit true beantworten. Kommt aber sicher auch wieder auf den Kontext an und entstammt mit Sicherheit irgendeinem gemurkse bei dem was völlig anderes gemeint ist.

Und wie schon ganz oben erwähnt : GOOGLE ! Ich dachte du kennst mitlerweile das Motto dieses Forums : Wenn es konkrete Fragen zu konkreten Problemen gibt geben wir gerne Hilfestellung zur Selbsthilfe, wir erledigen aber nicht die Arbeit für andere. Und du bist hier eigentlich aktiv und lange genug Member um diese “Grundregeln” zu kennen.
Mal davon abgesehen gibt es ja doch den einen oder anderen wirklich kompetenten Fachbeitrag von dir (oder zumindest mit deinem User gepostet) der darauf schließen lässt das dir diese Grundlagen geläufig sein sollten.

“Banhammer” ist jetzt wirklich schon zum dritten Mal zu lesen, habe noch in Erinnerung wie das das letzte Mal angemeckert wurde,
verzichtet bitte auf solche Formulierungen, die der unbedarfte Leser als Moderator-Aussage verwechseln könnte, das bist du nicht, und weit davon entfernt

auf lange Sicht auch etwas auffällig, zwar einige Stufen besser als CyborgBeta, nicht schwer, aber eben auch über/ unter dem normalen Level,
versuche lieber keine Urteile über andere, speziell CyborgBeta, zu posten, dieses Verhältnis habe ich auch in Beobachtung,

Posting hier enthält bisschen was fachliches, wenn es nur Gemecker wäre hätte ich es evtl. gelöscht,
ideale Grundregel meist: nicht in Themen von CyborgBeta posten, da gibt es keine Entschuldigung, da musst du nicht hin,
kein normales Thema/ keine normalen User zu verteidigen wo CyborgBeta sich vielleicht ungebührlich eingemischt,

wenn du in einem Thema von CyborgBeta postest und dann Flamewar, dann allein dein Fehler, vermeidbar

Andersherum, private/default/protected → public, gibt es (zumindest von der IDE) eine Warnung, „Objekte“ sollen nicht durch eine API bewegt öffentlich gemacht werden.

Meine Ansicht:
Überschreiben funktioniert nur in abgeleiteten Klassen,
Überladen funktioniert auch in abgeleiteten Klassen,
Verdecken… klar… lokale Var. hat selben Namen wie z. B. Attribut,
Schadowing… das ist mir unklar, oder ich muss raten,

kannst du noch mal bitte Deine Definition von Member/s schreiben? Das ist auch ein schwammiger Begriff, den wahrscheinlich einige viel zu weit fassen.

Ansonsten, keine Streitigkeiten bitte, Danke für deinen Beitrag. :wink: :slight_smile:

Genau. Das ist praktisch der Sinn vom Ableiten/Vererben.

Genau.

[QUOTE=CyborgBeta;119252]Verdecken… klar… lokale Var. hat selben Namen wie z. B. Attribut,
Schadowing… das ist mir unklar, oder ich muss raten,[/QUOTE]
Jain, Überschatten und Überschreiben sind beide praktisch äquivalent zueinander, werden nur durch einen anderen Effekt ausgelöst.

  • Beim Überschatten überschattet/verdeckt eine Variable mit dem selben Namen eine andere weil sie in einem höheren Geltungsbereich liegt und den Zugriff auf die untere Variable dadurch verhindert.
    (Das ist nochmals der Code von Timothy-Truckle - oben)
      private Object myTest;
      private void shadowingTest(){
        Object myTest= "diese lokale Variable Versteckt/Überschattet/shadowed die gleichnamige Member-Variable.";
     }
    }
  • Beim Verdecken überschattet/verdeckt eine Variable einer Kindklasse die gleichnamige Variable der Elternklasse
class Super {
      private Object myTest = "Diese Variable wird in der Klasse Test verdeckt";
}
class Test extends Super{
      private Object myTest;
}

Zwischen den Beiden zu unterscheiden ist wie zwischen Eis und Eiscreme zu unterscheiden - irrelevant.

Dabei hätte ich eine so gute Antwort auf

kannst du noch mal bitte Deine Definition von Member/s schreiben? Das ist auch ein schwammiger Begriff, den wahrscheinlich einige viel zu weit fassen.

parat. Da Verschattet es mir doch die Überladung!

[QUOTE=Bleiglanz]Dabei hätte ich eine so gute Antwort auf

kannst du noch mal bitte Deine Definition von Member/s schreiben? Das ist auch ein schwammiger Begriff, den wahrscheinlich einige viel zu weit fassen.

parat. Da Verschattet es mir doch die Überladung![/QUOTE]

Ich meine, jeder versteht unter Member etwas anderes, afaik. Aber Thema ist mMn. gelöst.

[quote=CyborgBeta]
Das ist auch ein schwammiger Begriff, den wahrscheinlich einige viel zu weit fassen.[…]
Ich meine, jeder versteht unter Member etwas anderes, afaik.[/quote]

Laß mich raten:

Der Gedanke, dass du einen schwammigen Begriff hast und Probleme mit einem einfachen, klaren Konzept (mit dem alle anderen kein Problem haben) - den hast du noch nicht gedacht.

[QUOTE=Bleiglanz]Laß mich raten:

Der Gedanke, dass du einen schwammigen Begriff hast und Probleme mit einem einfachen, klaren Konzept (mit dem alle anderen kein Problem haben) - den hast du noch nicht gedacht.[/QUOTE]
Dann erkläre doch mal, was für dich ein Member ist. Manche verstehen darunter alles, was eine Variable, Klasse, abstrakt oder Interface ist (also alles). Ist das richtig? Diese Mysterien oder nebulösen Begriff hab ich mir ja nicht ausgedacht. Unabhängig davon ist das Thema doch schon [gelöst]. Machs gut.

‘Member java’ liefert in Suchmaschinen Links wie
https://docs.oracle.com/javase/tutorial/java/javaOO/variables.html
die API-Klasse (!) Member (Java Platform SE 7 )
5 Objektorientiertes Programmieren mit Java
Was ist in Java eine Membervariable? (Computer)

alles übereinstimmend, was soll da ‘Klasse, abstrakt oder Interface’ mit zu tun haben?
wenn du dich wie immer auf Gerüchte ohne Zitate oder Links dahinter beziehst, nun ja, nicht überraschend

allein vermeinliche Member in Interfacen können etwas komisch aussehen,
aber auch nur weil Java da das Weglassen des static für Konstante sprachlich zuläßt
Java Blog Buch : 04.08 Interfaces (vs. Mehrfachvererbung)

Lies doch mal nach (SlaterB hat dir ja die Links gegeben), macht jeder Anfänger am Anfang mal.

Jeder Anfänger, der das am Anfang mal nachgelesen hat, wird die Begriffe Mysterium oder nebulös in diesem Zusammenhang unpassend finden.

Ist ein Synonym für Mann = Mit-Glied, ist doch klar.