Thoughts on agile software development
Jens 
Immer wieder kommt es vor, dass bei der Integration verschiedener Systeme von einer Enum Darstellung in eine andere konvertiert werden muss. Wer dem Fluch ausgesetzt ist, automatisch generierten Source-Code verwenden zu müssen, kennt dieses Ärgernis zur Genüge. Der Dummheit der Source-Code Generatoren gedankt, muss der Entwickler mit einer Vielzahl strukturell ähnlicher Klassen jonglieren.
Anti-Pattern sind die schwarzen Schafe unter den Pattern. Sie zeigen eine schlechte Lösung für ein bekanntes Problem. Damit helfen sie aber auf zweierlei Weise, sie warnen vor falschen Entscheidungen und sie helfen bei der Analyse, wenn irgendwas nicht richtig läuft.
Neue Anforderungen und Anwendungsfälle für selbstgeschrieben Bibliotheken ergeben sich häufig in Gesprächen mit Kollegen. In diesem Fall benötigte der Kollege eine Feiertagsliste für seinen Kalender. Die Bibliothek zur Feiertagsberechnung war für sein Problem unzureichend.
Immer wieder müssen Software Entwickler neue APIs aus dem Boden stampfen und sich dabei überlegen, wie sie die neue API denn gestalten wollen. Es gibt eine Unmenge von Möglichkeiten, wie man Klassen und Methoden benennt, welche Pattern die API nutzt und welches grundlegende Konzept verfolgt wird.
In der objektorientierten Softwareentwicklung können Objekte in zwei unterschiedliche Kategorien eingruppiert werden. Entweder sie sind nicht veränderbar (immutable) oder veränderbar (mutable).
Diese Unterscheidung hat nicht nur eine philosophische Größe, sie zeigt auch Konsequenzen in der tagtäglichen Programmierung. Der Großteil der Klassen, mit dem der Entwickler in Berührung kommt sind Mutables.
Die ersten drei Beiträge dieser Reihe handelten von einer Java API zur Feiertagsberechnung. In diesem Beitrag geht es um eine nachtragliche Verbesserung der Internationalisierung (I18N) und der minimalinvasiven Implementierung mit Hilfe des Decorator Design-Pattern.
Kaum ein Bereich in der Software Entwicklung gebiert so furchtbare Töchter wie die Sortierung. Obwohl die Java Standard Bibliothek viele wunderbare Klassen bereitstellt, finden sich immer wieder Programmierer, die ihre eigenen Holzwege schaffen.
Schaut man in irgendeine Code-Basis, dann finden sich immer Fragmente, die zur Generierung von Textdarstellungen dienen. Ob es sich um Inhalt einer Bestätigungs-Email, die Ausgabe von Rechnungsläufen oder eines Statusreports handelt. Je nach technologischer Reife der Systeme finden sich zur Erzeugung solcher Texte einfache String-Konkatenationen, String.printf Lösungen auf Konstanten oder Dateien, fluent Builder-APIs, eigene Template Engines oder erprobte Lösungen wie etwa FreeMarker.
Lange war es in Java nicht möglich eine Annotation an einer bestimmten Position mehrfach anzugeben. Dieses Manko wurde erst in der Java Version 8 durch Repeating Annotationsbehoben.
Im Beitrag Hamcrest Matcher Generator wurde die @Hamcrest Annotation vorgestellt. Diese Annotation gestattet es, für eine angegebene Klasse, Hamcrest Matcher automatisch zu erstellen.
Leider kann in der initialen Version des Generators immer nur eine @HamcrestAnnotation an einer Klasse stehen.
Hin und wieder schleichen sich I18N Anforderungen in die eigenen Anwendungen ein, die als einsprachige Anwendung gestartet wurde. Der offensichtlichste Fall für solch eine Mehrsprachigkeit ist z.B. eine Serviceseite im Kita Bereich. Da häufig Kinder verschiedenster Nationalitäten eine Kita besuchen, sind Informationen in der Muttersprache der Eltern hilfreich.