1. Dashboard
  2. Forum
    1. Unerledigte Themen
  3. Mitglieder
    1. Letzte Aktivitäten
    2. Benutzer online
    3. Team-Mitglieder
    4. Trophäen
    5. Mitgliedersuche
  4. Tutorial Bereich
  • Anmelden
  • Registrieren
  • Suche
Dieses Thema
  • Alles
  • Dieses Thema
  • Dieses Forum
  • Seiten
  • Forum
  • Lexikon
  • Erweiterte Suche
  1. Informatik Forum
  2. Webmaster & Internet
  3. Entwicklung

Protected-Verhalten.

  • LordNecro
  • 29. April 2010 um 11:43
  • Unerledigt
  • LordNecro
    11
    LordNecro
    Mitglied
    Reaktionen
    40
    Punkte
    1.140
    Beiträge
    211
    • 29. April 2010 um 11:43
    • #1

    Hallo ich hab gerade ein kleines Problem in Java. Ich habe versucht zwischen 2 Klassen eine Abstrakte Klasse in der Hierachie einzufügen. Ich hab das Problem mal mit Dummy Klassen nachgestellt:

    Code
    package pack1;
    
    
    public class A {
    
    
        protected int i;
    
        public void A(int i){
            this.i=i;
        }
    
    
    }
    Alles anzeigen

    davon erbt B

    Code
    package pack2;
    
    
    import pack1.A;
    
    
    public abstract class B extends A {
    
    
    }

    und zu guter letzt erbt hiervon C

    Code
    package pack2;
    
    
    
    
    public class C extends B{
    
    
        public C() {
    
        }
    
        public void blabla(C var){
            if (this.i==var.i){
    
            }
        }
    }
    Alles anzeigen

    soweit funktioniert das ganze, wenn ich allerdings den Parameter Typen von C auf B ändere, was mehr oder minder der Sinn des ganzen war:

    Code
    package pack2;
    
    
    
    
    public class C extends B{
    
    
        public C() {
    
        }
    
        public void blabla(B var){
            if (this.i==var.i){
    
            }
        }
    }
    Alles anzeigen

    unterwellt er mir im if das var.i mit der Meldung das i nicht visible sei.
    Nur das verstehe ich nicht, sowohl B und C erben von A was man ja auch daran sieht das this.i immer geht. Warum gehts aber mit var.i nicht?

    Einmal editiert, zuletzt von LordNecro (29. April 2010 um 11:53)

  • Paulchen
    1
    Paulchen
    Gast
    • 29. April 2010 um 11:49
    • #2
    Zitat von LordNecro

    Warum gehts aber mit var.i nicht?

    B ist in einem anderen Package als C.

  • LordNecro
    11
    LordNecro
    Mitglied
    Reaktionen
    40
    Punkte
    1.140
    Beiträge
    211
    • 29. April 2010 um 11:54
    • #3
    Zitat von Paulchen

    B ist in einem anderen Package als C.

    Sry Typo, B und C sind im gleichen Package.

  • JohnFoo
    20
    JohnFoo
    Mitglied
    Reaktionen
    61
    Punkte
    4.231
    Beiträge
    761
    • 29. April 2010 um 12:39
    • #4

    Wenn ich in einer Datei folgenden Code schreibe, funktioniert alles wie erwartet:

    Code
    class A {
    	protected int i;
    }
    
    
    abstract class B extends A {
    
    
    }
    
    
    class C extends B {
    	public void doSomething(C var) {
    		if (i == var.i) {
    
    
    		}
    	}
    }
    Alles anzeigen

    Kann deinen Fehler also nicht ganz nachvollziehen. Nachdem aber jetzt dein Beispiel schon einen Fehler zu haben scheint, könnte es ja vielleicht auch in anderen Aspekten vom Original abweichen - vielleicht in etwas, das du als unwichtig übersiehst. Zeig mal den Original-Code her, dann lässt sich das Problem vielleicht erkennen.

  • LordNecro
    11
    LordNecro
    Mitglied
    Reaktionen
    40
    Punkte
    1.140
    Beiträge
    211
    • 29. April 2010 um 12:43
    • #5
    Zitat von JohnFoo

    Kann deinen Fehler also nicht ganz nachvollziehen. Nachdem aber jetzt dein Beispiel schon einen Fehler zu haben scheint, könnte es ja vielleicht auch in anderen Aspekten vom Original abweichen - vielleicht in etwas, das du als unwichtig übersiehst. Zeig mal den Original-Code her, dann lässt sich das Problem vielleicht erkennen.



    Du musst in der Parameterliste von doSomething den Typen von var auf B ändern, dann solltest den Fehler haben den ich nicht verstehe.

  • Paulchen
    1
    Paulchen
    Gast
    • 29. April 2010 um 12:44
    • #6
    Zitat von JohnFoo

    Wenn ich in einer Datei folgenden Code schreibe

    ... dann liegt alles in demselben Package. In LordNecros Beispiel ist aber A in pack1 und B und C sind in pack2.

    Hab mir jetzt schnell in der Java Language Specification die Regelungen zu "protected" angesehen, wirklich schlau werd ich daraus allerdings nicht.

  • JohnFoo
    20
    JohnFoo
    Mitglied
    Reaktionen
    61
    Punkte
    4.231
    Beiträge
    761
    • 29. April 2010 um 13:09
    • #7
    Zitat von LordNecro

    Du musst in der Parameterliste von doSomething den Typen von var auf B ändern, dann solltest den Fehler haben den ich nicht verstehe.

    Habe ich jetzt gemacht, ändert nichts.

    Zitat von Paulchen

    ... dann liegt alles in demselben Package. In LordNecros Beispiel ist aber A in pack1 und B und C sind in pack2.

    Tut es. Die packages hat er ja als "Typo" bezeichnet, ich habe ihn so verstanden, dass doch alle Klassen im gleichen Paket liegen.

    Das Problem taucht auch nur auf, wenn man die Klassen in verschiedenen packages platziert. Das liegt daran, dass "protected" bedeutet, dass das Feld nur zu Subklassen im eigenen package hin sichtbar ist, nicht allgemein zu jeder erbenden Klasse hin.

    "protected" Felder sind zur Subklasse hin sichtbar, jedoch nur, wenn sie im gleichen package liegt. Wenn man packages als Module betrachtet, das nur über (public-)Schnittstellen kommunizieren sollte, dann ist das Verhalten durchaus sinnvoll.

  • LordNecro
    11
    LordNecro
    Mitglied
    Reaktionen
    40
    Punkte
    1.140
    Beiträge
    211
    • 29. April 2010 um 13:14
    • #8
    Zitat von JohnFoo

    Das Problem taucht auch nur auf, wenn man die Klassen in verschiedenen packages platziert. Das liegt daran, dass "protected" bedeutet, dass das Feld nur zu Subklassen im eigenen package hin sichtbar ist, nicht allgemein zu jeder erbenden Klasse hin.


    A liegt in package1, B und C liegen im package2. Dieser Aussage oben muss ich leider wiedersprechen. Wäre i nur im aktuellen Package sichtbar würden die geerbten Klassen ausserhalb des package1( also im package2) gar keinen member i haben. Den haben sie aber, wie man durch this.i ganz leicht erkennen kann.

  • LordNecro
    11
    LordNecro
    Mitglied
    Reaktionen
    40
    Punkte
    1.140
    Beiträge
    211
    • 29. April 2010 um 13:25
    • #9

    Ich habe das Problem mittlerweile in nem Dokument von Java gefunden.
    http://java.sun.com/docs/books/jls…/names.doc.html

    Hier unter 6.6.7. Neues Problem an dem ganzen: Die Begründung ist für mich absolut nicht logisch, vieleicht kann mir das jemand irgendwie anschaulich machen.

    Die Quintessenz scheint zu sein, das der Parameter von der aufrufenden Klasse erben muss bzw die aufrufende Klasse ist.
    Und da B nicht von C erbt sondern umgekehrt gehts nicht.

    EDIT: ne das kanns auch nicht sein sonst ginge im 6.6.7 Bsp Wrap

    2 Mal editiert, zuletzt von LordNecro (29. April 2010 um 13:34)

  • JohnFoo
    20
    JohnFoo
    Mitglied
    Reaktionen
    61
    Punkte
    4.231
    Beiträge
    761
    • 29. April 2010 um 17:14
    • #10
    Zitat von LordNecro

    A liegt in package1, B und C liegen im package2. Dieser Aussage oben muss ich leider wiedersprechen.

    Aja, absolut .. schräg! Und die Beschreibung machts auch nicht gerade leicht verständlich ..

  • Ringding
    11
    Ringding
    Mitglied
    Reaktionen
    12
    Punkte
    1.237
    Beiträge
    244
    • 30. April 2010 um 00:28
    • #11

    Das Verhalten der Vererbungen und Rechte ist in Java tatsächlich recht kompliziert und unüberschaubar. Ich habe das Gefühl, dass ein Großteil der Komplexität daher kommt, dass die Sichtbarkeit bzw. Nicht-Sichtbarkeit im Gegensatz zu C++ auch auf Binary-Ebene greifen muss. In C++ kann man ja locker mal in einem Headerfile etwas von private auf public umstellen und damit eine Object-Datei compilieren, die auf das private Feld zugreift; das ganze linkt man dann mit dem restlichen, normal compilierten Code zusammen und hat damit die Zugriffskontrolle ausgehebelt. In Java geht das einfach nicht.

  • JohnFoo
    20
    JohnFoo
    Mitglied
    Reaktionen
    61
    Punkte
    4.231
    Beiträge
    761
    • 30. April 2010 um 00:47
    • #12
    Zitat von Ringding

    Das Verhalten der Vererbungen und Rechte ist in Java tatsächlich recht kompliziert und unüberschaubar.

    Die zahlreichen Belege dafür wären mir unbekannt. Hättest du Beispiele? Das von LordNecro beschriebene Problem ist noch das komplexeste, das ich bisher gesehen habe.

    Zitat

    In C++ kann man ja locker mal in einem Headerfile etwas von private auf public umstellen und damit eine Object-Datei compilieren, die auf das private Feld zugreift;

    An den Regeln selbst scheint das ja nichts zu ändern - und ob das ein Vorteil ist, sei dahingestellt: Wenn Sichtbarkeiten sich derart leicht umgehen lassen, dann ist es nicht weit her mit der Sicherheit.

  • Ringding
    11
    Ringding
    Mitglied
    Reaktionen
    12
    Punkte
    1.237
    Beiträge
    244
    • 4. Mai 2010 um 23:53
    • #13
    Zitat von JohnFoo

    Die zahlreichen Belege dafür wären mir unbekannt. Hättest du Beispiele? Das von LordNecro beschriebene Problem ist noch das komplexeste, das ich bisher gesehen habe.


    Also ich hab mir jetzt auch mal das Kapitel aus der langspec durchgelesen, und es klingt tatsächlich alles recht naheliegend und unkompliziert. Nachdem ich mit Java aber typischerweise eher auf der Bytecode-Ebene zu tun hatte, weiß ich von dort, dass es schon einige Überraschungen im Zusammenhang mit protected gibt, z.B. http://dow.ngra.de/2008/11/03/when-protected-isnt-protected/

  • Maximilian Rupp 27. Dezember 2024 um 00:26

    Hat das Thema aus dem Forum Programmieren nach Entwicklung verschoben.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden

Benutzer online in diesem Thema

  • 1 Besucher

Rechtliches

Impressum

Datenschutzerklärung