6.4 Privatsphäre und Sichtbarkeit

Innerhalb einer Klasse sind alle Funktionen und Attribute für die Methoden sichtbar. Damit die Daten einer Klasse vor externem Zugriff geschützt sind und Methoden nicht von außen aufgerufen werden können, verbietet das Schlüsselwort private allen von außen zugreifenden Klassen den Zugriff.

In der UML werden private Eigenschaften mit einem führenden Minus gekennzeichnet.

Hier klicken, um das Bild zu Vergrößern

Abbildung 6.4 Ein privates Attribut pass

class Password
{
  private String pass = "";

  void setPassword( String oldpass, String newpass )
  {
    if ( oldpass != null && oldpass.equals(pass) )
    {
      pass = newpass;
      System.out.println( "Passwort gesetzt." );
    }
    else
      System.out.println( "Passwort konnte nicht gesetzt werden." );
  }
}

Wir sehen, dass öffentliche Objektmethoden ganz selbstverständlich auf das private-Element zugreifen können.

Eine Klasse PassDemo will nun auf das Passwort von außen zugreifen.

Listing 6.7 PassDemo.java, Teil 2

public class PassDemo
{
  public static void main( String args[] )
  {
    Password pwd = new Password();
    pwd.setPassword( "", "TeutoburgerWald" );
    pwd.setPassword( "TeutoburgerWald", "Doppelkeks" );
    pwd.setPassword( "Dopplerkeks", "panic" );
    //    System.out.println( pwd.pass );   // Compilerfehler
  }
}

Die Klasse Password enthält den privaten String pass, und dieser kann nicht referenziert werden. Der Compiler erkennt zur Übersetzungs- beziehungsweise Laufzeit Verstöße und meldet diese. So schreibt zum Beispiel der Compiler Jikes von IBM zur Übersetzungszeit:

19.     System.out.println( pwd.pass );   // Compilerfehler
                                <

Allerdings wäre es manchmal besser, wenn der Compiler uns nicht verraten würde, dass das Element privat ist, sondern einfach nur melden würde, dass es dieses Element nicht gibt.

Hier klicken, um das Bild zu Vergrößern

Bei einem durch die falsche Sichtbarkeit verursachten Fehler bietet Eclipse mit (Strg)+(1) eine Änderung der Sichtbarkeit an.

Hier klicken, um das Bild zu Vergrößern

6.4.1 Wieso nicht freie Methoden und Variablen für alle?

Private Funktionen und Variablen dienen in erster Linie dazu, den Klassen Modularisierungsmöglichkeiten zu geben, die von außen nicht sichtbar sein müssen. Zwecks Strukturierung werden Teilaufgaben in Funktionen gegliedert, die aber von außen nie alleine aufgerufen werden dürfen. Da die Implementierung versteckt wird und der Programmierer vielleicht nur eine Zugriffsfunktion sieht, wird auch der Terminus »Data Hiding« verwendet. Nehmen wir zum Beispiel ein Radio. Von außen bietet es die Funktionen an(), aus(), lauter() und leiser() an, aber wie es ein Radio zum Musikspielen bringt, ist eine ganz andere Frage, die wir als gewöhnliche Benutzer eines Radios lieber nicht beantwortet wissen wollen.

Dem unerlaubten Zugriff steht der freie Zugriff auf Funktionen und Variablen entgegen. Eingeleitet wird dieser durch das Schlüsselwort public. Damit ist von außen jederzeit ein Zugriff möglich. Wird weder public, protected noch private verwendet, so ist ein Zugriff von außen nur innerhalb des Pakets möglich. Damit können Gruppen von Klassen gebildet werden, die gegenseitig Teile ihres Innenlebens kennen. Von außerhalb des Pakets ist der Zugriff auf diese Teile dann untersagt, analog zu private. Anmerkung zur Disko: Die Disko beschäftigt illegale Mexikanerinnen. Der Gast sieht aber nur, dass er seine Getränke von einer Bedienung bekommt und weiß nicht, in welchem Beschäftigungsverhältnis sie steht.

Der Einsatz von private zeigt sich besonders in Unterklassen, denn werden in einer Oberklasse Eigenschaften mit private gekennzeichnet, dann ist der Zugriff auf diese Funktionen in der Unterklasse nicht erlaubt. Interessieren diese Informationen auch manche Unterklassen, lassen sich die Methoden und Attribute protected deklarieren. Damit räumt eine Oberklasse den Unterklassen spezielle Privilegien ein. Mit protected sind die Mitglieder einer Klasse für die Unterklassen sichtbar und ebenso im gesamten Paket.

6.4.2 Privat ist nicht ganz privat. Es kommt darauf an, wer's sieht

Wir wollen sehen, dass es in einem Spezialfall für eine Referenz ref doch möglich ist, auf ein privates Attribut oder eine private Methode des referenzierten Objekts zuzugreifen. Dazu muss dieser Zugriff in der Methode einer Klasse stattfinden, in der die private-Eigenschaft oder -Methode selbst definiert ist. Das sehen wir am besten an einem Beispiel.

Listing 6.8 WhoMayUsePrivate.java

public class WhoMayUsePrivate
{
  public static void main( String args[] )
  {
    DiskoVergleicher m = new DiskoVergleicher();
    System.out.println( m.compare( new DiskoVergleicher() ) );
  }
}
class DiskoVergleicher
{
  private int priv = (int) Math.random();
  public boolean compare( DiskoVergleicher comp )
  {
    // Zugriff auf ein privates Element über comp.priv
    return priv == comp.priv;
  }
}

Interessant ist die Zeile unter dem Kommentar. Die Methode compare() der Klasse DiskoVergleicher vergleicht das eigene Attribut priv des aufrufenden Objekts mit dem Attribut des als Parameter übergebenen Objekts comp. An dieser Stelle sehen wir, dass der Zugriff auf comp.priv zulässig ist, obwohl priv privat ist. Dieser Zugriff ist aber erlaubt, da die compare()-Methode in der DiskoVergleicher-Klasse definiert ist und der Parameter ebenfalls vom Typ DiskoVergleicher ist. Mit Unterklassen funktioniert das schon nicht mehr. Private Attribute und Methoden sind also gegen Angriffe von außerhalb der definierenden Klasse geschützt.

6.4.3 Zugriffsmethoden für Attribute definieren

Bisher sind wir davon ausgegangen, dass Attribute eine tolle Sache sind und dass es für den Nutzer eines Objekts nur Vorteile hat, wenn dieser über die Attribute auf den Zustand des Objekts zugreifen kann. Leider ist das nicht immer ohne Probleme möglich, wie die nachfolgenden Fälle zeigen:

Namensgebung für Zugriffsmethoden

Wir sehen an diesen Beispielen, dass es gute Gründe dafür gibt, Attribute zu privatisieren und öffentliche Methoden zum Lesen und Schreiben anzubieten. Da diese Methoden auf die Attribute zugreifen, nennen sie sich auch Zugriffsmethoden. Für jedes Attribut wird eine Schreib- und Lesemethode definiert, für die es auch ein Namensschema laut JavaBean-Konvention gibt. Lesemethoden beginnen mit get-, Schreibmethoden mit set-. Hinter die Vorsilbe wird der Name des Attributs gesetzt. Bei boolean-Attributen darf es (und muss es in machen Fällen auch) statt getXXX() (auch) isXXX() heißen. Da die Programmentwicklung in der Regel mit englischen Bezeichnernamen erfolgt, kommt es zu unschönen Bezeichnernamen wie getAnzahlPersonen(), wer mit deutschen Namen arbeitet.

Hier klicken, um das Bild zu Vergrößern

Unser folgendes Beispiel soll eine Disko implementieren, in dem die Anzahl Personen und die Quadratmeterzahl privat sind, und hübsch durch Zugriffsfunktionen abgesichert sind. Im Fall der Quadratmeter gibt es setQuadratmeter() und getQuadratmeter(), im Fall der Anzahl Personen nur getAnzahlPersonen(), da die Anzahl Personen nur über die Inkrement- Dekrement-Funktion zu modifizieren ist. Eine Konsistenzprüfung soll verhindern, dass es eine Quadratmeteranzahl kleiner null gibt.

Listing 6.9 v3/Disko.java

package v3;
/**
 * Führt Zugriffsmethoden ein.
 */
public class Disko
{
  private int quadratmeter;    // Größe der Disco
  private int anzahlPersonen;  // Anzahl Personen in der Disco
  /**
   * Liefert Anzahl Quadratmeter der Disko.
   * 
   * @return Quadratmeter.
   */
  public int getQuadratmeter()
  {
    return quadratmeter;
  }
  /**
   * Setzt die Anzahl Quadratmeter der Disko.
   * 
   * @param qm  Neue Größe in Quadratmetern.
   */
  public void setQuadratmeter( int qm )
  {
    if ( qm > 0 )
      quadratmeter = qm;
    else
      System.out.print( "Quadratmeter kann nicht <= 0 sein!" );
  }
  /**
   * Person kommt in die Disko.
   */
  public void personRein()
  {
    anzahlPersonen++;
  }
 /**
  * Person verlässt die Disko.
  */
 public void personRaus()
  {
    if ( anzahlPersonen > 0 )
    anzahlPersonen--;
  }
  /**
   * Liefert Anzahl Personen in der Disco.
   * 
   * @return Anzahl Personen.
   */
  public int getAnzahlPersonen()
  {
    return anzahlPersonen;
  }
}

An den Methoden wird eine weitere Konvention sichtbar. Die Hole-Methode getXXX() besitzt keinen Parameter, und der Typ vom Rückgabewert ist der gleiche wie der von der Variablen quadratmeter. Die set-Methode hat keinen Rückgabewert, aber genau einen Parameter vom Typ des Attributs. Letzteres gilt für die anfängliche Programmerstellung. Wird später bei der Weiterentwicklung des Programms eine Änderung nötig, beispielsweise muss die Quadratmeteranzahl ja nicht ganzzahlige Werte annehmen, kann der Typ der internen Variablen geändert werden und die Welt draußen bekommt davon nichts mit. Lediglich eine kleine Typanpassung muss in der Implementierung von setQuadratmeter() und getQuadratmeter() vorgenommen werden. Sicherlich ist es keine gute Idee, sich bei ungültigen Werten taub zu stellen, sondern eine Fehlermeldung zu produzieren. Das kann etwa in Form einer Ausnahme geschehen.

Hier klicken, um das Bild zu Vergrößern

Steht der Cursor auf einer Objekteigenschaft, so fördert Source, Generate Setter und Getter... ein Dialogfenster hervor, mit dem Eclipse automatisch die setXXX()- und getXXX()-Methoden einfügen kann.

Hier klicken, um das Bild zu Vergrößern

6.4.4 Zusammenfassung zur Sichtbarkeit

Der Einsatz der Sichtbarkeitsstufen über die Schlüsselworte public, private und protected und der Standard »paketsichtbar« ohne explizites Schlüsselwort sollte überlegt erfolgen. Objektorientierte Programmierung zeichnet sich durch durchdachten Einsatz von Klassen und deren Beziehungen aus. Am besten ist die einschränkendste Beschreibung, also nie mehr Öffentlichkeit als notwendig.

6.4.5 Sichtbarkeit in der UML

Für die Sichtbarkeit von Attributen und Operationen sieht die UML unterschiedliche Symbole vor, die vor die jeweilige Eigenschaft gesetzt werden:

¹ Na ja, Zombies laufen ja oft genug in einer Disko rum.