package demo.api;

public interface IQuoter {
        String quote(String s);
}

Dazu steuern die Entwickler eine Implementierung für den deutschen Sprachraum bei, welcher tief- und hochgestellte Anführungszeichen verwendet (über Unicode):

package demo.impl;

public class GermanQuoter implements IQuoter {
        public String quote(String s) {
                return '\u201E' + s + '\u201D';
        }
}

Die Frage ist nun, wie kann man diese Implementierung verwenden,

• ohne sie direkt in der Applikation zu importieren und
• ohne sie direkt in der API zu referenzieren?

Die Lösung ist interessanterweise bereits seit dem JDK 1.3 Teil der Java Standard Edition (SE), auch wenn sie zwischen den Versionen einige Male den Platz gewechselt hat. Mit Java 6 scheint sie nun aber ihren endgültigen Platz gefunden zu haben als java.util.ServiceLoader.

Dafür muß die Implementierung als eigenes JAR ausgeliefert werden, denn folgende Punkte sind Voraussetzung für die Nutzung des ServiceLoader:

1. im JAR muß ein Verzeichnis META-INF/services vorhanden sein
2. in diesem Verzeichnis muß für jede API Klasse (Interface oder abstrakte Klasse) eine Datei gleichen Namens liegen
3. in jeder dieser Dateien muß der vollqualifizierte Namen der Implementations-Klasse vermerkt sein

Für unser Beispiel bedeutet das also, daß der Inhalt des Implementierungs-JAR wie folgt aussieht:
demo.impl.GermanQuoter
META-INF/services/demo.api.IQuoter

Und die einzige Zeile in der Datei demo.api.IQuoter liest sich wie folgt:
demo.impl.GermanQuoter

Wie kommt nun unsere Applikation, welche die API und das Implementierungs-JAR im Klassenpfad hat an die Implementierung? Nun, über Aufruf der entsprechenden Service Locator, welche sich je nach JDK an verschiedenen Stellen finden:

• im JDK 1.3 als sun.misc.Service
• im JDK 1.4 – 1.5 als javax.imageio.spi.ServiceRegistry(!)
• seit dem JDK 1.6 endlich an richtiger Stelle als java.util.ServiceLoader

Also schreiben wir uns für das JDK 1.6 eine kleine, generische Utility-Klasse, welche eine oder alle Implementierungen für eine API-Artefakt liefern kann:

package demo.util;

import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;
import java.util.ServiceLoader;

public final class GenericServiceLocator {

    private GenericServiceLocator() {
    }

    public static <T> T locate(final Class<T> clazz) {
        final List services = locateAll(clazz);
        return services.isEmpty() ? (T) null : services.get(0);
    }

    public static <T> List<T> locateAll(final Class<T> clazz) {

        final Iterator<T> iterator = ServiceLoader.load(clazz).iterator();
        final List<T> services = new ArrayList<T>();

        while(iterator.hasNext()) {
            try {
                services.add(iterator.next());
            } catch (Error e) {
                e.printStackTrace(System.err);
            }
        }

        return services;

    }
}

Und so sieht dann der Aufruf aus unserer Beispiel-Applikation aus:

package demo;

import demo.api.IQuoter;
import demo.util.GenericServiceLocator;

public class App {
    public static void main( String[] args ) {
        System.out.println(
                GenericServiceLocator
                    .locate(IQuoter.class)
                    .quote("Quote Me")
        );
    }
}

Das ist alles. Befinden sich API, Implementierung und Applikation im Klassenpfad, kann der Test über den Aufruf von
java -cp demo-api.jar;demo-impl.jar;demo-app.jar demo.App
erfolgen. Das Ergebnis sollte auf Unicode-Terminals ein „Quote Me” sein. Auf der Windows XP Console ist es übrigens äQuote Meö …

Zum Ausprobieren ist das Beispiel-Projekt als Maven2 Multi-Module beigefügt, die Verwendung in eigenen Projekten ist – selbstverständlich – gestattet.

Der Beitrag Abhängigkeiten vermeiden mit der Java Service Provider Spezifikation erschien zuerst auf dahlen.org.

Metriken

Viele der eingesetzen Werkzeuge (wie JDepend, CAP, SonarJ) verwenden Metriken, die bereits 1994 von Robert Martin als OO Design Quality Metrics1 definiert wurden. Die maßgeblichen Kennzahlen dabei sind:

• die Abstraktheit (abstractness, A) einer Kategorie
• die Instabilität (instability, I) einer Kategorie
• die Distanz (distance, D) einer Kategorie zur Ideallinie, der sog. main sequence

Der Begriff „Kategorie” beschreibt in diesem Kontext eine logische Gruppierung innerhalb der Architektur, hierbei könnte es sich z.B. um eine Java Library, ein Java Package oder ein Maven Modul handeln.

Abstraktheit

Die Abstraktheit wird nun aus dem Verhältnis von „abstrakten” (N_a) zur Summe aller Klassen gebildet (abstrakte und „konkrete”, N_c). Im Java-Kontext schließt die Qualifizierung als „abstrakt” dabei auch Interfaces mit ein. Es gilt:

A = N_a : (N_a + N_c)

Der Wertbereich ist [0,1], kann also als Prozentzahl wiedergegeben werden. 0% bedeutet, das die Kategorie ausschließlich aus konkreten Klassen besteht, 100% bedeutet, daß die Kategorie ausschließlich aus abstrakten Klassen oder Interfaces besteht.

Instabilität

Zur Bestimmung der Instabilität verwendet R. Martin die Abhängigkeiten einer Kategorie von anderen Kategorien. Dabei unterscheidet er zwischen eingehenden Abhängigkeiten (afferent couplings, C_a) und ausgehenden Abhängigkeiten (efferent couplings, C_e).

Afferent couplings sind also Abhängigkeiten, welche andere Kategorien in die betrachtete Kategorien haben, efferent couplings sind Abhängigkeiten, welche die betrachtete Kategorie in andere Kategorien hat.

Wieder wird das Verhältnis gebildet, es gilt:

I = C_e : (C_e + C_a)

Auch hier kann der Wertebereich [0,1] in Prozent ausgedrückt werden. Je mehr ausgehende Abhängigkeiten eine Kategorie hat, desto höher ist der Grad an Instabilität. I ist also 0 für Kategorien, die keinerlei ausgehende Abhängigkeiten haben und 1 für Kategorien, die ausschließlich ausgehende Abhängigkeiten haben.

Main Sequence

Die für eine Kategorie ermittelte Abstraktheit A und Instabilität I lassen sich hervorragend als Achsen eines Graphen verwenden. Jede Kategorie kann dann als Koordinate in das System eingetragen werden. Doch welche Aussage lässt sich aus ihrer Plazierung machen?

A=1, I=0

eine Kategorie, die zu 100% abstrakt ist und keinerlei ausgehende Abhängigkeiten hat, ist eine API. Interfaces und abstrakte Klassen definieren dabei die notwendigen Operationen, welche durch eine konkrete Implementierung zu realisieren sind

A=0, I=1

eine Kategorie, die zu 0% abstrakt ist und ausschließlich abgehende Abhängigkeiten hat, ist eine Implementierung. Am Ende der Vererbungskette realisiert sie z.B. eine API

A=1, I=1

eine Kategorie, die zu einem hochgradig abstrakt ist und andererseits ausschließlich abgehende Abhängigkeiten hat, stellt keinen erstrebenswerten Zustand dar. Als API ist sie zu instabil, als Implementierung müssten konkrete Klassen vorhanden sein

A=0, I=0

Kategorien, welche stabil und konkret sind, haben ihre Berechtigung als geschlossenes, kleines System. Ein klassisches Beispiel dafür ist das typische HelloWorld.java, lässt man die Abhängigkeiten zu den JRE/JEE Bibliotheken außen vor. In größeren Architekturen wird dieser Punkt vermutlich nie erreicht werden.

In der Theorie von R. Martin bildet die Strecke zwischen den Extremen von A und I nun die sog. Main Sequence (A + I = 1). Sie beschreibt das Verhältnis zwischen Abstraktheit und Instabilität, welches als ausgewogen (balanced) gilt.

Distanz

Die oben beschriebenen Kennzahlen dienen bisher nur der Einordnung einer Kategorie in den Graphen. Zur Bestimmung der „Güte” einer Kategorie empfiehlt R. Martin nun die Berechnung der Distanz (distance) einer Kategorie von der main sequence. Es gilt:

D = |(A + I – 1) : 2|

oder einfacher (um einen Wert zwischen 0 und 1 zu erhalten):

D = |A + I – 1|

Ziel des objekt-orientierten Design sollte es nun sein, die Distanz nahe an 0 zu bringen, etwa indem man ausgehende Abhängigkeiten eliminiert und damit die Stabilität erhöht, oder Kategorien in APIs mit hoher Abstraktheit und Implementierungs-Bereiche unterteilt.

Fazit

Die oben aufgeführten Metriken können eine Hilfe beim objekt-orientieren Design bzw. der objekt-orientierten Analyse sein. Man sollte sich ihnen aber nicht blind unterwerfen, denn wie immer gilt: Das Ideal im Blick, das Projektziel unter den Fingern.

¹ Robert Martin: OO Design Quality Metrics – An Analysis of Dependencies, 1994

Der Beitrag Qualitätsmetriken des OOD erschien zuerst auf dahlen.org.