Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Java ist auch eine Sprache
2 Sprachbeschreibung
3 Klassen und Objekte
4 Der Umgang mit Zeichenketten
5 Mathematisches
6 Eigene Klassen schreiben
7 Angewandte Objektorientierung
8 Exceptions
9 Generics, innere Klassen
10 Die Klassenbibliothek
11 Threads und nebenläufige Programmierung
12 Datenstrukturen und Algorithmen
13 Raum und Zeit
14 Dateien und Datenströme
15 Die eXtensible Markup Language (XML)
16 Grafische Oberflächen mit Swing
17 Grafikprogrammierung
18 Netzwerkprogrammierung
19 Verteilte Programmierung mit RMI und Web–Services
20 JavaServer Pages und Servlets
21 Applets
22 Midlets und die Java ME
23 Datenbankmanagement mit JDBC
24 Reflection und Annotationen
25 Logging und Monitoring
26 Sicherheitskonzepte
27 Java Native Interface (JNI)
28 Dienstprogramme für die Java-Umgebung
Stichwort

Download:
- ZIP, ca. 14,1 MB
Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Java ist auch eine Insel (8. Auflage) von Christian Ullenboom
Programmieren mit der Java Standard Edition Version 6
Buch: Java ist auch eine Insel (8. Auflage)

Java ist auch eine Insel (8. Aufl.)
8., aktual. Auflage, geb., mit DVD
1.475 S., 49,90 Euro
Galileo Computing
ISBN 978-3-8362-1371-4
Pfeil 7 Angewandte Objektorientierung
Pfeil 7.1 Schnittstellen in der Anwendung
Pfeil 7.1.1 CharSequence als Beispiel einer Schnittstelle
Pfeil 7.1.2 Die Schnittstelle Iterable
Pfeil 7.1.3 Funktionszeiger
Pfeil 7.2 Design-Pattern (Entwurfsmuster)
Pfeil 7.2.1 Motivation für Design-Pattern
Pfeil 7.2.2 Das Beobachter-Pattern (Observer/Observable)
Pfeil 7.2.3 Ereignisse über Listener
Pfeil 7.3 Service-Factory
Pfeil 7.3.1 Arbeiten mit dem ServiceLoader
Pfeil 7.3.2 Utility-Klasse Lookup als ServiceLoader-Fassade
Pfeil 7.4 JavaBean
Pfeil 7.4.1 Properties (Eigenschaften)
Pfeil 7.4.2 Einfache Eigenschaften
Pfeil 7.4.3 Indizierte Eigenschaften
Pfeil 7.4.4 Gebundene Eigenschaften
Pfeil 7.4.5 Veto-Eigenschaften – dagegen!


Galileo Computing - Zum Seitenanfang

7.2 Design-Pattern (Entwurfsmuster) Zur nächsten ÜberschriftZur vorigen Überschrift

Aus dem objektorientierten Design haben wir gelernt, dass Klassen nicht fest miteinander verzahnt, sondern lose gekoppelt sein sollen. Das bedeutet: Klassen sollten nicht zu viel über andere Klassen wissen, und die Interaktion soll über wohldefinierte Schnittstellen erfolgen, sodass die Klassen später noch verändert werden können. Die lose Kopplung hat viele Vorteile, da so die Wiederverwendung erhöht und das Programm änderungsfreundlicher wird. Wir wollen dies an einem Beispiel prüfen:

In einer Datenstruktur sollen Kundendaten gespeichert werden. Zu dieser Datenquelle gibt es eine grafische Oberfläche, die diese Daten anzeigt und verwaltet, etwa eine Eingabemaske. Wenn Daten eingegeben, gelöscht und verändert werden, sollen sie in die Datenstruktur übernommen werden. Den anderen Weg von der Datenstruktur in die Visualisierung werden wir gleich beleuchten. Bereits jetzt haben wir eine Verbindung zwischen Eingabemaske und Datenstruktur, und wir müssen aufpassen, dass wir uns im Design nicht verzetteln, denn vermutlich läuft die Programmierung darauf hinaus, dass beide fest miteinander verbunden sind. Wahrscheinlich wird die grafische Oberfläche irgendwie über die Datenstruktur Bescheid wissen, und bei jeder Änderung in der Eingabemaske werden direkt Methoden der konkreten Datenstruktur aufgerufen. Das wollen wir vermeiden. Genauso haben wir nicht bedacht, was passiert, wenn nun infolge weiterer Programmversionen eine grafische Repräsentation der Daten etwa in Form eines Balkendiagramms gezeichnet wird. Und was geschieht, wenn der Inhalt der Datenstruktur über andere Programmfunktionen geändert wird und dann einen Neuaufbau der Bildschirmdarstellung erzwingt? Hier verfangen wir uns in einem Knäuel von Methodenaufrufen, und änderungsfreundlich ist dies dann auch nicht mehr. Was ist, wenn wir nun unsere selbst gestrickte Datenstruktur durch eine SQL-Datenbank ersetzen wollen?


Galileo Computing - Zum Seitenanfang

7.2.1 Motivation für Design-Pattern Zur nächsten ÜberschriftZur vorigen Überschrift

Wir sind nicht die Ersten, die sich über grundlegende Design-Kriterien Gedanken machen. Vor dem objektorientierten Programmieren (OOP) gab es das strukturierte Programmieren, und die Entwickler waren froh, mit Werkzeugen schneller und einfacher Software bauen zu können. Auch die Assembler-Programmierer waren erfreut, strukturiertes Programmieren zur Effizienzsteigerung einsetzen zu können – sie haben ja auch Unterprogramme nur deswegen eingesetzt, weil sich mit ihnen wieder ein paar Bytes sparen ließen. Doch nach Assembler und strukturiertem Programmieren sind wir nun bei der Objektorientierung angelangt, und dahinter zeichnet sich bisher kein revolutionäres Programmierparadigma ab. Die Softwarekrise hat zu neuen Konzepten geführt, doch merkt fast jedes Entwicklungsteam, dass OO nicht alles ist, sondern nur ein verwunderter Ausspruch nach drei Jahren Entwicklungsarbeit an einem schönen Finanzprogramm: »Oh, oh, alles Mist.« So schön OO auch ist, wenn sich 10.000 Klassen im Klassendiagramm tummeln, ist das genauso unübersichtlich wie ein FORTRAN-Programm mit 10.000 Zeilen. Da in der Vergangenheit oft gutes Design für ein paar Millisekunden Laufzeit geopfert wurde, ist es nicht verwunderlich, dass Programme nicht mehr lesbar sind. Doch wie am Beispiel vom Satzprogramm TeX (etwa 1985) zu sehen ist: Code lebt länger als Hardware, und die nächste Generation von Mehrkernprozessoren wird sich bald in unseren Desktop-PCs nach Arbeit sehnen.

Es fehlt demnach eine Ebene über den einzelnen Klassen und Objekten, denn die Objekte selbst sind nicht das Problem, vielmehr ist es die Kopplung. Hier helfen Regeln weiter, die unter dem Stichwort Entwurfsmuster (engl. design patterns) bekannt geworden sind. Dies sind Tipps von Softwaredesignern, denen aufgefallen ist, dass viele Probleme auf ähnliche Weise gelöst werden können. Sie stellten daher Regelwerke mit Lösungsmustern auf, die eine optimale Wiederverwendung von Bausteinen und Änderungsfreundlichkeit aufweisen. Design-Patterns ziehen sich durch die ganze Java-Klassenbibliothek, und die bekanntesten sind Beobachter-(Observer-)Pattern, Singleton, Fabrik (Factory) und Composite; die Fabrik und das Singleton haben wir bereits kennengelernt.


Galileo Computing - Zum Seitenanfang

7.2.2 Das Beobachter-Pattern (Observer/Observable) Zur nächsten ÜberschriftZur vorigen Überschrift

Wir wollen uns nun mit dem Observer-Pattern beschäftigen, das seine Ursprünge in Smalltalk-80 hat. Dort ist es etwas erweitert unter dem Namen MVC (Model-View-Controller) bekannt, ein Kürzel, mit dem auch wir uns noch näher beschäftigen müssen, da dies ein ganz wesentliches Konzept bei der Programmierung grafischer Bedieneroberflächen mit Swing ist.

Stellen wir uns eine Party mit einer netten Gesellschaft vor. Hier finden sich zurückhaltende passive Gäste und aktive Erzähler. Die Zuhörer sind interessiert an den Gesprächen der Unterhalter. Da die Erzähler nun von den Zuhörern beobachtet werden, bekommen sie den Namen Beobachtete, auf Englisch auch Observables (Beobachtbare) genannt. Die Erzähler interessieren sich jedoch nicht dafür, wer ihnen zuhört. Für sie sind alle Zuhörer gleich. Sie schweigen aber, wenn ihnen überhaupt niemand zuhört. Die Zuhörer reagieren auf Witze der Unterhalter und werden dadurch zu Beobachtern (engl. observers).

Die Klasse Observable und die Schnittstelle Observer

Unser Beispiel mit den Erzählern und Zuhörern können wir auf Datenstrukturen übertragen. Die Datenstruktur lässt sich beobachten und wird zum Beobachteten. Sie wird in Java als Exemplar der Bibliotheksklasse Observable repräsentiert. Der Beobachter wird durch die Schnittstelle Observer abgedeckt und ist der, der informiert werden will, wenn sich die Datenstruktur ändert. Jedes Exemplar der Observable-Klasse informiert nun alle seine Horcher, wenn sich sein Zustand ändert. Denken wir wieder an unser ursprüngliches Beispiel mit der Visualisierung. Wenn wir nun zwei Sichten auf die Datenstruktur haben, etwa die Eingabemaske und ein Balkendiagramm, ist es der Datenstruktur egal, wer an den Änderungen interessiert ist. Ein anderes Beispiel: Die Datenstruktur enthält einen Wert, der durch einen Schieberegler und ein Textfeld angezeigt wird. Beide Bedienelemente wollen informiert werden, wenn sich dieser Wert ändert. Es gibt viele Beispiele für diese Konstellation, sodass die Java-Entwickler die Klasse Observable und die Schnittstelle Observer mit in die Standardbibliothek aufgenommen haben. Noch besser wäre die Entscheidung gewesen, die Funktionalität in die oberste Klasse Object aufzunehmen, so wie es Smalltalk macht.

Die Klasse Observable

Eine Klasse, deren Exemplare sich beobachten lassen, muss jede Änderung des Objektzustands nach außen hin mitteilen. Dazu bietet die Klasse Observable die Methoden setChanged() und notifyObservers() an. Mit setChanged() wird die Änderung angekündigt, und mit notifyObservers() wird sie tatsächlich übermittelt. Gibt es keine Änderung, so wird notifyObservers() auch niemanden benachrichtigen.

Wir wollen nun das Party-Szenario in Java implementieren. Dazu schreiben wir eine Klasse JokeTeller, deren Objekte einen Witz erzählen können. Sie machen mit setChanged() auf eine Änderung ihres Zustands aufmerksam und versorgen dann mit notifyObservers() die Zuhörer mit dem Witz in Form einer Zeichenkette.

Listing 7.8 com/tutego/insel/pattern/observer/JokeTeller.java

package com.tutego.insel.ds.observer; 
 
import java.util.*; 
 
class JokeTeller extends Observable 
{ 
  private static final List<String> jokes = Arrays.asList( 
    "Sorry, aber du siehst so aus, wie ich mich fühle.", 
    "Eine Null kann ein bestehendes Problem verzehnfachen.", 
    "Wer zuletzt lacht, hat es nicht eher begriffen.", 
    "Wer zuletzt lacht, stirbt wenigstens fröhlich.", 
    "Unsere Luft hat einen Vorteil: Man sieht, was man einatmet." 
  ); 
 
  public void tellJoke() 
  { 
    setChanged(); 
    Collections.shuffle( jokes ); 
    notifyObservers( jokes.get(0) ); 
  } 
}

setChanged() setzt intern ein Flag, das von notifyObservers() abgefragt wird. Nach dem Aufruf von notifyObservers() wird dieses Flag wieder gelöscht. Dies kann auch manuell mit clearChanged() geschehen. notifyObservers() sendet nur dann eine Benachrichtigung an die Zuhörer, wenn auch das Flag gesetzt ist. So kommen folgende Programmzeilen häufig zusammen vor, da sie das Flag setzen und alle Zuhörer informieren.

setChanged();               // Eine Änderung ist aufgetreten 
notifyObservers( Object );  // Informiere Observer über Änderung

Die notifyObservers()-Methode existiert auch ohne extra Parameter. Sie entspricht einem notifyObservers(null). Mit der Methode hasChanged() können wir herausfinden, ob das Flag der Änderung gesetzt ist.

Interessierte Beobachter müssen sich am Observable-Objekt mit der Methode addObserver(Observer) anmelden. Dabei sind aber keine beliebigen Objekte als Beobachter erlaubt, sondern nur solche, die die Schnittstelle Observer implementieren. Sie können sich mit deleteObserver(Observer) wieder abmelden. Die Anzahl der angemeldeten Observer teilt uns countObservers() mit. Leider ist die Namensgebung etwas unglücklich, da Klassen mit der Endung »able« eigentlich immer Schnittstellen sein sollten. Genau das ist hier aber nicht der Fall. Der Name Observer bezeichnet überraschenderweise eine Schnittstelle, und hinter dem Namen Observable verbirgt sich eine echte Klasse.

Die Schnittstelle Observer

Das aktive Objekt, der Sender der Nachrichten, ist ein Exemplar der Klasse Observable, das Benachrichtigungen an angemeldete Objekte schickt. Das aktive Objekt informiert alle zuhörenden Objekte, die die Schnittstelle Observer implementieren müssen.

Jetzt können wir für die Party auch die Zuhörer implementieren.

Listing 7.9 com/tutego/insel/pattern/observer/JokeListener.java

class JokeListener implements Observer 
{ 
  final private String name; 
 
  JokeListener( String name ) 
  { 
    this.name = name; 
  } 
 
  @Override public void update( Observable o, Object arg ) 
  { 
    System.out.println( name + " lacht über: \"" + arg + "\"" ); 
  } 
}

interface java.util.Observer

  • void update( Observable o, Object arg )
    Wird bei Benachrichtigungen vom Observable o aufgerufen. Als zweites Argument trifft die über notifyObservers(Object) verschickte Nachricht ein. Bei der parameterlosen Variante notifyObservers() ist der aktuelle Parameter null.

Da auf einer echten Party die Zuhörer und Erzähler nicht fehlen dürfen, baut die dritte Klasse Party nun echte Stimmung auf.

Listing 7.10 com/tutego/insel/pattern/observer/Party.java

package com.tutego.insel.ds.observer; 
 
import java.util.*; 
 
public class Party 
{ 
  public static void main( String[] args ) 
  { 
    Observer achim    = new JokeListener( "Achim" ); 
    Observer michael  = new JokeListener( "Michael" ); 
    JokeTeller chris  = new JokeTeller(); 
 
    chris.addObserver( achim ); 
 
    chris.tellJoke(); 
    chris.tellJoke(); 
 
    chris.addObserver( michael ); 
 
    chris.tellJoke(); 
 
    chris.deleteObserver( achim ); 
 
    chris.tellJoke(); 
  } 
}

Wir melden zwei Zuhörer nacheinander an und einen wieder ab. Dann geht das Lachen los.


Galileo Computing - Zum Seitenanfang

7.2.3 Ereignisse über Listener topZur vorigen Überschrift

Eine Erweiterung der Möglichkeiten über Observer/Observable sind Listener. Es gibt Ereignisauslöser, die spezielle Ereignis-Objekte aussenden, und Interessenten, die sich bei den Auslösern an- und abmelden – sie werden in Java Listener genannt. Die beteiligten Klassen und Schnittstellen folgen einer bestimmten Namenskonvention; XXX steht im Folgenden stellvertretend für einen Ereignisnamen.

  • Eine Klasse für die Ereignisobjekte heißt XXXEvent. Die Ereignisobjekte können Informationen wie Auslöser, Zeitstempel und weitere Daten speichern.
  • Die Interessenten implementieren als Listener eine Java-Schnittstelle, die XXXListener heißt. Die Operation der Schnittstelle kann beliebig lauten, doch wird ihr üblicherweise das XXXEvent übergeben. Anders als beim Observer/Observable kann diese Schnittstelle auch mehrere Operationen vorschreiben.
  • Der Ereignisauslöser bietet Methoden addXXXListener(XXXListener) und removeXXXListener(XXXListener) an, um Interessenten an- und abzumelden. Immer wenn ein Ereignis stattfindet, erzeugt der Auslöser das Ereignisobjekt XXXEvent und informiert jeden Listener, der in der Liste eingetragen ist, über einen Aufruf der Methode aus dem Listener.

Die beteiligten Typen soll ein Beispiel verdeutlichen.

Radios spielen Werbung

Ein Radio soll für Werbungen AdEvent-Objekte aussenden. Die Ereignis-Objekte sollen den Werbespruch (Slogan) speichern.

Listing 7.11 com/tutego/insel/pattern/listener/AdEvent.java

package com.tutego.insel.pattern.listener; 
 
import java.util.EventObject; 
 
public class AdEvent extends EventObject 
{ 
  private String slogan; 
 
  public AdEvent( Object source, String slogan ) 
  { 
    super( source ); 
    this.slogan = slogan; 
  } 
 
  public String getSlogan() 
  { 
    return slogan; 
  } 
}

Die Klasse AdEvent erweitert EventObject, eine Klasse, die alle Ereignis-Klassen erweitern. Der parametrisierte Konstruktor von AdEvent nimmt im ersten Parameter den Ereignisauslöser an und gibt ihn mit super(source) an den Konstruktor der Oberklasse weiter, der ihn speichert und mit getSource() wieder verfügbar macht. Der zweite Parameter vom AdEvent-Konstruktor ist unsere Werbung.

Der AdListener ist die Schnittstelle, die Interessenten implementieren:

Listing 7.12 com/tutego/insel/pattern/listener/AdListener.java

package com.tutego.insel.pattern.listener; 
 
import java.util.EventListener; 
 
/** The listener interface for receiving ad events. */ 
interface AdListener extends EventListener 
{ 
  /** Invoked when an ad occurs. */ 
  void advertisement( AdEvent e ); 
}

Unser AdListener implementiert die Schnittstelle EventListener (eine Markierungsschnittstelle), die alle Java-Listener implementieren sollen. Wir schreiben für konkrete Listener nur eine Operation advertisement() vor.

Das Radio soll nun Interessenten an- und abmelden können. Es sendet über einen Timer Werbenachrichten. Das Spannende an der Implementierung ist die Tatsache, dass die Listener nicht in einer eigenen Datenstruktur verwaltet werden, sondern eine spezielle Listener-Klasse aus dem Swing-Paket verwendet wird.

Listing 7.13 com/tutego/insel/pattern/listener/Radio.java

package com.tutego.insel.pattern.listener; 
 
import java.util.*; 
import javax.swing.event.EventListenerList; 
 
public class Radio 
{ 
  /** List of listeners. */ 
  private EventListenerList listeners = new EventListenerList(); 
 
  /** All advertisements. */ 
  private List<String> ads = Arrays.asList( "Jetzt explodiert auch der Haarknoten", 
                                            "Red Fish verleiht Flossen", 
                                            "Bom Chia Wowo", 
                                            "Wunder Whip. Iss milder." ); 
 
  /** Radio with frequent ads. */ 
  public Radio() 
  { 
    new Timer().schedule( new TimerTask() 
    { 
      @Override public void run() 
      { 
          Collections.shuffle( ads ); 
          notifyAdvertisement( new AdEvent( this, ads.get(0) ) ); 
      } 
    }, 0, 500 ); 
  } 
 
  /** 
   * Adds an {@code AdListener} to the radio. 
   * @param l the {@code AdListener} to be added 
   */ 
  public void addAdListener( AdListener listener ) 
  { 
    listeners.add( AdListener.class, listener ); 
  } 
 
  /** 
   * Removes an {@code AdListener} from the radio. 
   * @param l the listener to be removed 
   */ 
 
  public void removeAdListener( AdListener listener ) 
  { 
    listeners.remove( AdListener.class, listener ); 
  } 
 
  /** 
   * Notifies all {@code AdListener}s that have registered interest for 
   * notification on an {@code AdEvent}. 
   * @param event  the {@code AdEvent} object 
   * @see EventListenerList 
   */ 
  protected synchronized void notifyAdvertisement( AdEvent event ) 
  { 
    for ( AdListener l : listeners.getListeners( AdListener.class ) ) 
      l.advertisement( event ); 
  } 
}

Die Demo-Anwendung nutzt das Radio-Objekt und implementiert einen konkreten Listener.

package com.tutego.insel.pattern.listener; 
 
public class RadioDemo 
{ 
  public static void main( String args[] ) 
  { 
    Radio r = new Radio(); 
 
    class ComplainingAdListener implements AdListener { 
      @Override public void advertisement( AdEvent e ) { 
        System.out.println( "Oh nein, schon wieder Werbung: " + e.getSlogan() ); 
      } 
    } 
 
    r.addAdListener( new ComplainingAdListener() ); 
  } 
}


Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.






<< zurück
  Zum Katalog
Zum Katalog: Java ist auch eine Insel





Java ist auch eine Insel
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Tipp
Zum Katalog: Coding for Fun





 Coding for Fun


 Buchempfehlungen
Zum Katalog: Objektorientierte Programmierung





 Objektorientierte
 Programmierung


Zum Katalog: Einstieg in Eclipse 3.4






 Einstieg in
 Eclipse 3.4


Zum Katalog: Java 6 lernen mit Eclipse






 Java 6 lernen
 mit Eclipse


Zum Katalog: NetBeans Platform 6






 NetBeans
 Platform 6


Zum Katalog: Java und XML






 Java und XML


Zum Katalog: Visual C# 2008






 Visual C# 2008


Zum Katalog: IT-Handbuch für Fachinformatiker






 IT-Handbuch für
 Fachinformatiker


Zum Katalog: C++ von A bis Z






 C++ von A bis Z


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2009
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de