Verwirrung über Modifizierer!?



  • Hi,

    bin Anfänger und hab da so meine Probleme den Einsatz von Modifizierern zu verstehen. Die Theorie ist ja sehr einfach, doch beim praktischen Einsatz blicke ich nicht mehr ganz so durch. Der Autor meines Lehrbuches blökt sich kanpp 30 Seiten über die Modifizierer aus, übernimmt das aber keineswegs bei seinen späteren Beispielen im Buch. Auch spricht er anfangs immer vom eleganten und für die Laufzeit performanteren plazieren von Definitionen von Membervariablen außerhalb des Konstruktors.Zwei Beispiele die in dem Buch so
    auftauchen und ein und das selbe darstellen:

    class meinMenu
    extends MenuBar
    {
        public meinMenu()
        {
          Menu menu = new Menu("Datei");
          MenuItem item = new MenuItem("Neu");
          menu.add(item);
          this.add(menu);
        }
    }
    

    oder

    class meinMenu
    extends MenuBar
    {
        Menu menu;
        MenuItem item;
    
        public meinMenu()
        {
          menu = new Menu("Datei");
          item = new MenuItem("Neu");
          menu.add(item);
          this.add(menu);
        }
    }
    

    Hier wird nur der Default-Status gesetzt, aber nicht public, private oder was anderes. Auch werden die Variablen menu und item im Konstruktor erzeugt. In anderen Büchern, beispielsweise Das Java Codebook von Addison-Wesley, sieht das so aus.

    class meinMenu
    extends Frame
    {
        private Menu menu = new Menu("Datei);
        private MenuItem item = new MenuItem("Neu");
    
        public meinMenu()
        {
          menu.add(item);
          this.add(menu);
        }
    }
    

    Für einen Anfänger natürlich ziemlich schwer zu verstehen.
    Welche Variante ist denn nun effektiver im Hinblick auf eleganten und performanten Quellcode? Hat es irgendwelche Auswirkungen, dass ich Obejktreferentenzen (Variablen vom Typ eines Objekt und an die später eine Instanz zugewiesen wird) außerhalb des Konstruktors definiere und was ist der Unterschied zu dem innerhalb (auch hier wieder Performance, Übersichtlichkeit, wie wirkt sich das auf die Compilierarbeit aus)?

    Und zu aller letzt die Sichtbarkeit und Sicherheit der Variablen mit private. Was bedeutet das für mein Programm wenn die Menüs und Menüeinträge innerhalb der Klasse meinMenu privat sind. Ist das aus irgendwelchen Gründen sicherer oder nicht so leicht anzugriefen (aber warum sollte ein Menü angegriffen werden)?? Kann ich dann bestimmte #Sachen mit dem Menü nicht mehr machen oder gerdae deshlab damit machen (Beispiele aus der Praxis)???

    Ich bedanke mich jetzt schon mal für eure Antworten. Das wird mir hoffentlich ein bischen helfen die Materie besser zu verstehen.

    Euer Freak2003



  • Hi,

    Freak2003 schrieb:

    Welche Variante ist denn nun effektiver im Hinblick auf eleganten und performanten Quellcode? Hat es irgendwelche Auswirkungen, dass ich Obejktreferentenzen (Variablen vom Typ eines Objekt und an die später eine Instanz zugewiesen wird) außerhalb des Konstruktors definiere und was ist der Unterschied zu dem innerhalb (auch hier wieder Performance, Übersichtlichkeit, wie wirkt sich das auf die Compilierarbeit aus)?

    du kannst die Objekte bereits in der Definition initialisieren, oder das ganze dem Konstruktor überlassen (der eigentlich dafür da ist). Ich persönlich bevorzuge die 2. Variante.

    Freak2003 schrieb:

    Und zu aller letzt die Sichtbarkeit und Sicherheit der Variablen mit private. Was bedeutet das für mein Programm wenn die Menüs und Menüeinträge innerhalb der Klasse meinMenu privat sind. Ist das aus irgendwelchen Gründen sicherer oder nicht so leicht anzugriefen (aber warum sollte ein Menü angegriffen werden)??

    Es geht darum, dass die Objekte ihre eigene Identität haben. Sie kapseln also bestimmte Eigenschaften und stellen Methoden bereit, die etwas mit diesen Eigenschaften anstellen können. Die Klasse kann dann selbst entscheiden, ob diese Eigenschaften nach außen sichtbar sein dürfen, und ob sie von anderen Klassen geändert werden können. Dafür kannst du dann öffentliche "setter" und "getter" Methoden definieren.

    public class Mensch {
    
    private int alter;
    
    public Mensch(int alter) {
       this.alter = alter;
    }
    
    public void setAlter(int alter) {
       this.alter = alter;
    }
    
    public int getAlter() {
       return alter;
    }
    }
    

    Wenn du das Attribut verbergen möchtest (d.h. es soll keiner erfahren, wie alt du bist), dann definierst du die getAlter() Methode nicht. Oder du kannst dir überlegen, dass nur bestimmte "befreundete" Klassen innerhalb desgleichen Pakets dies wissen dürfen und definierst du die Methode ohne public etc.

    Und noch was. Wieso lernst du Swing ?! ... oder ist es so ein bescheuertes Buch?

    kati



  • Kati schrieb:

    Und noch was. Wieso lernst du Swing ?! ... oder ist es so ein bescheuertes Buch?

    Bei dieser Frage bin ich mir nicht sicher, worauf du hinaus willst. Willst du damit sagen, dass Swing so intuitiv ist, dass man es nicht lernen braucht oder willst du ihm ein anderes Windowing-Toolkit (SWT beispielsweise) empfehlen? 🙂



  • CengizS schrieb:

    Kati schrieb:

    Und noch was. Wieso lernst du Swing ?! ... oder ist es so ein bescheuertes Buch?

    Bei dieser Frage bin ich mir nicht sicher, worauf du hinaus willst. Willst du damit sagen, dass Swing so intuitiv ist, dass man es nicht lernen braucht oder willst du ihm ein anderes Windowing-Toolkit (SWT beispielsweise) empfehlen? 🙂

    <glaskugel>Wie waere es mit dem allseits beliebten "ERST die Sprache lernen, DANN die Toolkits"?</glaskugel>

    Wuerde ich uebrigens auch empfehlen...



  • @Cengiz: ich habe eigentlich das gemeint, was SG1 auch gemeint hat. Er fängt ja erst an ... daher sollte er Grundlagen lernen und nicht wie man GUI programmiert. Also nichts gegen Swing (ich vergötte swing sowieso, wenn es schon drauf ankommen würde 😃 ), falls du dich angegriffen gefühlt hast 😃

    kati



  • Nöööö mir wars nur nicht klar 🙂



  • Hallo ihr,
    bin ebenfalls Neueinsteiger in Java und ich höre als Konstruktoren.
    Dachte in Java gäbe es keine solcher Konstruktoren...
    Zumindest nicht wie sie es in C++ gibt.

    Habe ich da was falsch verstanden oder wird hier der Name Konstruktor für eine
    ganz andere Struktur benutzt?



  • Da hast du vielleicht was falsch verstanden. Was es nicht gibt sind Destruktoren.



  • Ups, hab glaube ich eben , warum auch immer, unterbewusst Zeiger und Konstruktor durcheinander gebracht. Mit dem Konstruktor manipuliere ich ja keine Speicherbereiche.. Und das mit dem Destruktor ist dann sopwieso klar, weil das ja der CC übernimmt.


Anmelden zum Antworten