Gedanken zur agilen Softwareentwicklung
In den Beiträgen REST in Peace und REST heißt HATEOAS wurde schon auf die Möglichkeiten des HATEOAS Patterns hingewiesen. Die Verlinkung von Resourcen nutzen um innerhalb der Client Anwendung das notwendige Wissen um die Server API zu reduzieren, entkoppelt Systeme und vereinfacht die Entwicklung und Wartung. Auch in diesem Beitrag wird es um die Implementierung … Weiterlesen
Leider verhält es sich mit TODOs wie mit den Flaggen an Nord- und Südpol. Sie überdauern die Jahre und sehen hin und wieder enttäuschte Gesichter von Abenteurern, die zu spät gekommen sind.
Immer wieder müssen Strings in Java Applikationen zusammengefügt werden. Lange vorbei sind dabei die Zeiten, in denen der Entwickler selber die String Instanzen und einen Separator in einen StringBuilder stecken musste. Mittlerweile kann der Entwickler bei der Verwendung von Streams auf die Collectors.joining Methoden oder in anderen Fällen, auf den dahinter verborgenen StringJoiner, zurückgreifen.
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.