08/2008 - KaffeeKlatsch

Abgeschottet
deren, denen er das Objekt (großmütig) zur Verfügung
stellt, dieses auf keinen Fall ändern sollen. Vertrauen ist
gut, aber kein Schreibzugriff ist besser.
Die besten Voraussetzungen so etwas zu schaffen, hat
man mit Schnittstellen. Mit einer Schnittstelle hat man
ganz präzise Möglichkeiten, den Zugriff auf das Objekt
zu Beschreiben.
public interface ReadableValue {
public String getValue();
}
Ein solches Interface verrät nichts über die Implementierung
und bietet dabei alles, was der Anwender
wünscht.
public static void doIt(ReadableValue rv) {
… rv.getValue() …
}
Die Vorteile, die Interfaces generell mit sich bringen,
bleiben dabei natürlich erhalten: Lose Kopplung von
Klassen, Paketen oder Systemen; einfache Testbarkeit
mit Hilfe geeigneter Mock-Klassen; 3 und viele, viele
mehr.
Eine Implementierung muss nun nur diesem Interface
genügen, ansonsten gibt es keine Anforderungen an
die implementierende Klasse.
public class Value implements ReadableValue {
String value;
public Value(String value) {
this.value = value;
}
public void setValue(String value) {
this.value = value;
}
public String getValue() {
return value;
}
…
}
Die Unverbesserlichen – die „das geht schon in Ordnung,
ich weiß doch was ich tue“-Entwickler – könnten nun
einfach auf die Idee kommen aus dem ReadableValue
durch Casting ein Value machen. Das lässt sich aber
verhindern, indem man die Value-Klasse nur innerhalb
ihres Paketes bekannt macht.
3
Eine Mock-Klasse täuscht ein echte Klasse vor. Für das anwendende Programm
ist kein Unterschied bemerkbar, da doch nur die Schnittstelle verwendet wird.
Damit ist es relativ leicht, nutzende Programme zu testen, insbesondere kann
man dann auch mit Daten testen, die im realen Anwendungsfällen eigentlich
nicht auftreten können – es aber dann doch immer wieder tun.
Geregelte Verhältnisse
Will man nun eine Klasse doch für den Schreibzugriff
öffnen, so muss man sich überlegen, ob ein Schreibzugriff
einen Lesezugriff impliziert. Das ist zwar oft der Fall,
aber durchaus nicht immer sinnvoll.
public class Value implements Read, Write {
…
}
Eine Trennung von Read und Write ist deswegen sinnvoll,
weil nur so die beiden Schnittstellen unabhängig
voneinander entwickelt werden können.
interface ExtendedRead extends Read {
…
}
interface ExtendedWrite extends Write {
…
}
class ExtendedValue
extends Value
implements ExtendedRead
{
…
}
Letzteres hat dann leider nicht ganz so funktioniert wie
gewünscht, weil sich die Write-Schnittstelle doch über
die Value-Klasse eingeschlichen hat. Die einzige Lösung
des Problems ist – wenn es vorher nicht absehbar
ist, wie die Vererbung aussehen wird –, die Implementierungen
ebenfalls losgelöst von den Schnittstellen zu
halten.
class ValueAdapter {
…
}
class ExtendedValueAdapter extends ValueAdapter {
…
}
class Value
extends ValueAdapter
implements Read, Write
{
// nur Konstruktoren, wenn überhaupt
}
class ExtendedValue
extends ExtendedValueAdapter
implements ExtendedRead
{
// nur Konstruktoren, wenn überhaupt
}
Seite 12 KaffeeKlatsch Jahrgang 1 / Nr. 8 / August 2008