13
Nov
14

Eine Builder-Variante mit Initialisierungsblöcken

Eines der weniger oft genutzen Java-Features sind Initialisierungsblöcke. Aber wenn sie dann einmal gebraucht werden, können sie ziemlich nützlich sein. Vielleicht auch, um Builder zu schachteln? Und wie könnte das aussehen?

Nehmen wir an, wir müssten eine einfache hierarchische Struktur aufbauen: Eine Menü-Leiste, darin Menüs, und in diesen wiederum Menüpunkte. Mit Initialisierungsblöcken könnte der Aufruf dann so aussehen:

MenuBarBuilder menuBarBuilder = new MenuBarBuilder() {{
    new Menu("menu1") {{
        new Item("item1.1");
        new Item("item1.2");
    }};
    new Menu("menu2") {{
        new Item("item2.1");
        new Item("item2.2");
        new Item("item2.3");
    }};
}};

System.out.println(menuBarBuilder);

Der Einfachheit halber bauen wir hier das Menü nicht zusammen (was ja nicht schwer ist, wenn man die Builder-Struktur erst einmal hat), sondern geben einfach nur eine String-Repräsentation aus. Hier wäre das Ergebnis:

menubar[
  menu 'menu1'[item 'item1.1', item 'item1.2'], 
  menu 'menu2'[item 'item2.1', item 'item2.2', item 'item2.3']]

Okay, bis auf die geschweiften Doppel-Klammern sieht die Verwendungsseite eigentlich gar nicht so schlimm aus. Aber welche Scheußlichkeiten müssen wir bei der Implementierung begehen, damit das funktioniert? Ich finde, auch die Implementierung ist recht erträglich, denn wir benutzen einen einfachen Trick: Menu ist eine innere Klasse von MenuBarBuilder, und kann sich somit bei der Objekterzeugung bei “seiner” äußeren Instanz “registrieren” (in diesem Fall einfach in eine vorgegebene Liste eintragen). Genauso ist Item eine innere Klasse von Menu und registriert sich dort. Dieser Aufbau löst eine Menge Probleme – und es wird nicht einmal ein statischer Import benötigt. Hier ist der Code:

import java.util.ArrayList;
import java.util.List;

public class MenuBarBuilder {

    private List<Menu> menus = new ArrayList<>();

    public String toString() {
        return "menubar" + menus.toString();
    }

    public class Menu {
        private final String menuName;
        private List<Item> items = new ArrayList<>();

        public Menu(String name) {
            this.menuName = name;
            MenuBarBuilder.this.menus.add(this);
        }

        public String toString() {
            return "\n  menu '" + menuName + "'" + items;
        }

        public class Item {
            private final String itemName;

            public Item(String name) {
                this.itemName = name;
                Menu.this.items.add(this);
            }

            public String toString() {
                return "item '" + itemName + "'";
            }

        }
    }

}

Ja, das ist alles was man braucht, damit der Aufruf oben funktioniert. Im Endeffekt ergibt sich die Einfachheit daraus, dass wir die Builder genau so ineinanderschachteln, wie auch unsere Struktur später aussehen soll.

Wie ist diese Builder-Variante nun einzuschätzen? Der größte Nachteil ist wohl, dass sie durch die Verwendung von Initialisierungsblöcken einfach ungewohnt ist. Weiterhin skaliert dieser Ansatz nicht so gut: Bei tiefen Hierarchien wird die Builder-Klasse immer länger, weil immer neue innere Klassen dazukommen, die man nicht auslagern kann. Außerdem wird für jeden verwendeten Initialisierungsblock eine anonyme Klassen erzeugt und eine entsprechende class-Datei angelegt, was bei viel geschachteltem “Inhalt” ebenfalls problematisch sein kann (allerdings würde in diesem Fall auch das “normale” Builder-Pattern unbequem werden). Auf der Haben-Seite dieses Konstrukts steht ein recht einfacher Aufbau und eine hohe Flexibilität.

Ehrlich gesagt bin ich mir nicht sicher, ob die vorgestellte Builder-Variante eine gute Idee ist, aber es war auf jeden Fall spannend, damit herumzuspielen, und überraschend, wie gut sie funktioniert.

09
Sep
14

Popularität Programmiersprachen – 2014-08

Hallo Leute,

hier sind die Statistiken des Monats August.

Popularität der Programmiersprachen für August 2014:
(Zuwachs oder Schrumpfung in Prozent über die 13 vorherigen Monate)

Popularität Programmiersprachen 2014-08 - Rangfolge

Popularität der Programmiersprachen für August 2014:
(Statistische Zahlen zu den Sprachen)

Popularität Programmiersprachen 2014-08 - Statistische Zahlen

INFO: Die Statistiken für den September und Oktober erscheinen Anfang November.

Viel Spasz weiterhin
Falk

09
Sep
14

Popularität Programmiersprachen – 2014-07

Hallo Leute,

hier sind die Statistiken des dritten Monats.

Popularität der Programmiersprachen für Juli 2014:
(Zuwachs oder Schrumpfung in Prozent über die 13 vorherigen Monate)

Popularität Programmiersprachen 2014-07 - Rangfolge

Popularität der Programmiersprachen für Juli 2014:
(Statistische Zahlen zu den Sprachen)

Popularität Programmiersprachen 2014-07 - Statistische Zahlen

Viel Spasz weiterhin
Falk

09
Sep
14

Popularität Programmiersprachen – 2014-06

Hallo Leute,

hier sind die Statistiken des zweiten Monats. Neben der Veränderung in Prozent und den statistischen Zahlen gibt es nun noch die Veränderung des Ranges. Eine Null steht dabei für keine Veränderung im Rang, positive Zahlen für ein Aufsteigen und negative Zahlen für ein Absteigen im Rang.

Popularität der Programmiersprachen für Juni 2014:
(Zuwachs oder Schrumpfung in Prozent über die 13 vorherigen Monate)

Popularität Programmiersprachen 2014-06 - Rangfolge

Popularität der Programmiersprachen für Juni 2014:
(Statistische Zahlen zu den Sprachen)

Popularität Programmiersprachen 2014-06 - Statistische Zahlen

Viel Spasz weiterhin
Falk

07
Sep
14

Popularität Programmiersprachen – 2014-05

Hallo Leute,

da dies meine erste Veröffentlichung auf diesem Blog ist, möchte ich mich kurz vorstellen. Mein Name Falk, ich bin 38 Jahre alt, komme aus Dresden und bin gerade mit meinem zweiten Studium der Informationstechnik fertig geworden. Ab jetzt bin ich Java-Entwickler in Dresden. Ich kenne Daniel seit zwei Jahren – der Grund hierfür war Scala.

Da ich mich seit längerem mit der Popularität von Programmiersprachen beschäftige und dazu eine Statistik führe, gab es von uns die Idee, diese Statistik hier auf diesem Blog zu veröffentlichen.

Die Quelle zu dieser Statistik ist lediglich die Seite stackoverflow.com, deren Genehmigung für die Erhebung und Veröffentlichung ich mir bereits eingeholt habe. Täglich um 14:00 mitteleuropäischer Zeit wird die Anzahl an Fragen von insgesamt 54 Programmiersprachen erfasst. Mit diesen Zahlen wird dann eine Statistik erstellt. Aus den Zahlen zum monatsletzten Tag, werden die durchschnittlichen Fragen pro Sprache und Tag für den Monat errechnet. Anschlieszend wird für jede Sprache der Anteil der Fragen von allen 54 Sprachen für einen Monat berechnet. Aus diesen monatlichen Prozentangaben, über den Zeitraum von 13 Monaten, werden dann die Parameter der Regressionsgerade bestimmt. Aus der Höhendifferenz der Regressionsgerade erhält man den Zuwachs oder die Schrumpfung des Prozentanteils von allen Sprachen. In Abhängigkeit von diesem Anteil, werden Sprachen mit wenigen Fragen von der weiteren Betrachtung ausgeschlossen. Aus diesem Grund ist die Summe der Prozentanteile nicht genau Null. Die übriggebliebenen Sprachen werden nach ihrem Anteil sortiert und in einem Diagramm dargestellt. Solch ein Diagramm soll monatlich erscheinen. Zusätzlich zu diesem Diagramm soll die durchschnittliche Fragenanzahl der letzten 13 Monate pro Tag angegeben werden und für jede übriggebliebene Sprache, die durchschnittliche Fragenanzahl pro Tag (über die letzten 13 Monate), die Differenz an Fragen über diese Zeit und der prozentuale Anteil dieser Differenz gegenüber der Fragenanzahl der letzten 13 Monate.

 

Popularität der Programmiersprachen für Mai 2014:
(Zuwachs oder Schrumpfung in Prozent über die 13 vorherigen Monate)

Popularität Programmiersprachen 2014-05 - Rangfolge

Popularität der Programmiersprachen für Mai 2014:
(Statistische Zahlen zu den Sprachen)

Popularität Programmiersprachen 2014-05 - Statistische Zahlen

Für diesen Monat und für jeden Dezember, wird der Verlauf der Fragenanzahl der 54 Fragen auf stackoverflow.com in einem Diagramm dargestellt:

Popularität Programmiersprachen 2014-05 - Fragen auf stackoverflow.com (54 Sprachen)

Viel Spasz weiterhin
Falk

29
Aug
14

Casts mit zusätzlichen Bounds in Java 8

Immer wieder beschert mir Java wundervolle WTF-Momente, so auch heute. Eine Syntaxerweiterung in Java 8, die komplett an mir vorbeigegangen ist, sind Casts mit zusätzlichen Bounds:

LinkedList<String> list = new LinkedList<>();
List<String> list1 = (List & Queue) list; //OK
List<String> list2 = (List & RandomAccess) list; //ClassCastException

Die JLS schreibt dazu recht lakonisch :

If the cast operator contains a list of types – that is, a ReferenceType followed by one or more AdditionalBound terms – then all of the following must be true, or a compile-time error occurs.

Stellt sich die Frage ist, wozu das Ganze gut sein soll. Der einzige sinnvolle Anwendungsfall, den ich gefunden habe, ist die Spezifizierung zusätzlicher Interfaces bei Lambdas:

Runnable r = (Runnable & Serializable) () -> System.out.println("Serializable!");

Lambdas haben ja eigentlich keinen Typ, sie sind ein wenig wie Schrödingers Katze: Erst wenn man etwas mit ihnen anstellt – etwa die Zuweisung zu einer Variablen – entscheidet sich, was ihr Typ ist. Durch den vorgelagerten Cast wird diese Typbestimmung vorgezogen, so dass das Objekt r nicht nur Runnable, sondern auch Serializable ist, und später auch problemlos serialisiert werden kann.

Wie findet ihr dieses etwas obskure Feature? Seht ihr noch andere sinnvolle Anwendungsmöglichkeiten?

02
Jun
14

Pattern-Matching in Java 8

In Scala ist Pattern-Matching ein beliebtes Feature mit fast unbegrenzten Anwendungsmöglichkeiten. Nicht umsonst wird es oft als “switch auf Steroiden” bezeichnet. Im Rahmen eines kleinen Projekts habe ich überlegt, ob man das nicht auch in Java 8 nachbauen kann.

Man kann, mit einigen Einschränkungen. Hier einmal ein kleines Anwendungsbeispiel:

String string = ...
String s = match(string,
   StartsWith("foo", () -> "found foo..."),
   EndsWith("bar", () -> "found ...bar"),
   Contains("baz", () -> "found ...baz..."),
   EqualsIgnoreCase("blubb", () -> "found blubb"),
   Default(() -> "nix gefunden")
);
System.out.println(s);

Wie funktioniert das? Zuerst braucht man für die einzelnen Fälle ein Interface:

import java.util.Optional;

public interface Case<T,R> {
    Optional<R> accept(T value);
}

Es ist im Prinzip eine Art Funktion, die für einem Ausgangswert ein Resultat liefert, allerdings in einem Optional. Wir haben also eine Art Funktion, die eventuell etwas zurückliefert – genau dann, wenn der zu überprüfende Wert “passt”. Hier eine der verwendeten Case-Implementierungen (man verzeihe mir bitte die an Scala angelehnte Großschreibung der Methodennamen):

public static <R> Case<String, R> StartsWith(String prefix, Supplier<R> supplier) {
    return t -> t.startsWith(prefix)
            ? Optional.of(supplier.get())
            : Optional.<R>empty();
}

Wir liefern also den durch den Supplier vorgegebenen Wert (in ein Optional verpackt) zurück, aber nur, wenn der zu testende String den richtigen Präfix hat.

Die match-Methode ist auch recht unspektakulär (MatchException ist eine gewöhnliche Laufzeit-Exception):

@SafeVarargs
public static <T,R> R match(T value, Case<T,R> ... cases) throws MatchException {
    for(Case<T,R> c : cases) {
        Optional<R> result = c.accept(value);
        if (result.isPresent()) {
            return result.get();
        }
    }
    throw new MatchException();
}

Interessanterweise kann dieser Mechanismus auch die Arbeit mit Optional vereinfachen. Wenn wir einmal so tun, als hätte Optional wie in Scala die Unterklassen Some (die einen Wert enthält) und None (die “leer” ist), könnte uns das zu dieser Verwendung anregen:

Optional<Integer> opt = ...
String s = match(opt,
        None(() -> "leer"),
        Some(42, () -> "die Antwort!"),
        SomeIf(a -> "gerade", a -> a % 2 == 0),
        Default(() -> "nix gefunden")
);

Selbst “geschachteltes” Pattern-Matching ist möglich:

Optional<Optional<Integer>> opt = ...
String s = match(opt,
        None(() -> "leer"),
        Some(None(() -> "leer eingetütet")),
        Some(SomeIf(a -> "gerade", a -> a % 2 == 0)),
        Default(() -> "nix gefunden")
);

Hier die verwendeten Case-Implementierungen:

import static java.util.Optional.*;
...

public static <T,R> Case<Optional<T>,R> None(Supplier<? extends R> supplier) {
    return t -> t.isPresent()
            ? Optional.<R>empty()
            : of(supplier.get());
}

public static <T,R> Case<Optional<T>,R> Some(T value, Supplier<? extends R> supplier) {
    return t -> t.isPresent() && t.get().equals(value)
            ? of(supplier.get())
             : Optional.<R>empty();
}

public static <T,R> Case<Optional<T>,R> Some(Case<T,R> caseT) {
    return t -> t.isPresent()
            ? caseT.accept(t.get())
            : Optional.<R>empty();
}

public static <T,R> Case<Optional<T>,R> Some(Function<? super T, ? extends R> fn) {
    return t -> t.isPresent()
            ? of(fn.apply(t.get()))
            : Optional.<R>empty();
}

public static <T,R> Case<Optional<T>,R> SomeIf(Function<? super T, ? extends R> fn, Predicate<T> predicate) {
    return t -> t.isPresent() && predicate.test(t.get())
            ? of(fn.apply(t.get()))
            : Optional.<R>empty();
}

public static <T,R> Case<T,R> Default(Supplier<R> supplier) {
    return value -> of(supplier.get());
}

Ich will nicht verhehlen, dass wir hier haarscharf an den Grenzen von Javas Typ-Inferenz operieren, und auch leicht Eindeutigkeitsprobleme bei gleichnamigen statischen Methoden mit Lambda-Argumenten auftreten können. Ob diese kleine DSL wirklich “brauchbar” ist, muss sich erst noch zeigen. Spaß macht es auf jeden Fall.




Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.