Category Archives: programming

GUIs deklarativ – never ending story


Flattr this

Motivation

Der Traum eine Programmoberfläche möglichst einfach, mit wenig Text und doch mit exakter Anordnung der GUI Elemente beschreiben zu können ist schon sehr alt. Immer wieder tauchten dazu Konzepte auf – doch diese konnten sich am Markt nie wirklich fortsetzen, nicht zu Letzt auch mangels der Unterstützung großer Firmen. Das letzte mir bekannte Exemplar ist JavaFX Script welches nun auch schon fast als ausgestorben bezeichnet werden kann.

Für alle die sich dennoch eine deklarative Sprache für die GUI Entwicklung wünschen zeigt dieser Artikel Projekte und mögliche Fortsetzungen auf.

Thinlet

Das erste mir bekannte Projekt welches seine GUI deklarativ beschrieb war Thinlet. Ich nenne es mal Thinlet one denn der Autor hat das Projekt inzwischen eingestampft und hat unter gleichem Namen ein völlig neues Framework herausgebracht. Letzteres konnte mich aber nicht weiter begeistern.

Das ursprüngliche Projekt war im Prinzip ein Jar mit einer Klasse. In dieser Klasse war die gesamte Logik. In der eigenen Anwendung waren die Oberflächen dann per xml zu beschreiben. Das Framework unterstützte sogar bereits das Binding von GUI Elementen an Java Klassen. Allerdings war das Eventhandling irgenwie nicht optimal gelöst – ich hatte damit jedenfalls Probleme – ich glaube mit der Richtung aus Java Klasse zum GUI Element oder von GUI Element zu GUI Element. Das kann ich leider nicht mehr genau sagen.

Dokumente zum ursprünglichen Projekt lassen sich kaum noch finden – man muss halt ein bisschen googeln denn die URLs wechseln stetig – aber offensichtlich gibt es noch genug Leute welche die Dokumentation retten. Hier ein Beispiel: http://wolfpaulus.com/thinlet/doc/widget/overview.html

Canoo

Diese Firma muss ich hier einfach aufzählen, weil sie mit ULC (Ultra Light Client) das fertiggestellt hat von dem alle Welt träumt. Allerdings proprietär und teuer 😦 Das war der Grund weshalb ihr Framework für den Open Source Bereich nicht in Frage kommt. Aber die Technologie ist genial – Half Object Plus Protocol (HOPP) Entwurfmuster. Das wäre das Ziel nur eben frei und Oracle hat es mit JavaFX eindeutig vermasselt. Hier ein Beispiel wie leicht alles gehen könnte.

GUI4J

Das GUI4J Projekt funktionierte ähnlich wie Thinlet wurde aber von mehr Leuten entwickelt und länger durchgehalten.

Zu guter Letzt gibt es natürlich tausende Projekte die in Richtung XML deklarierte Oberfläche gehen aber keine welches wirklich später dafür relevant wurde. Hier eine von vielen Listen die im Internet findbar sind: http://www.java2s.com/Product/Java/XML/XML-UI.htm

JavaFX

JavaFX in der ersten Version hatte mit JavaFX Script wirklich Potential den Sprung in Richtung Canoo zu schaffen. Doch Oracle hat es getötet aus welchen Gründen auch immer: http://www.heise.de/developer/meldung/Das-endgueltige-Aus-fuer-JavaFX-Script-1444903.html

JavaFX selbst hat Oracle dennoch zur Schlüsseltechnologie erhoben. Bislang steht diese allerdings irgendwo außerhalb des aktiv von Oracle gepushten ADF. ADF selbst setzt weiterhin auf Swing und eine dirty Click and Drop Oberfläche. Letztere hinterlässt in der Praxis nach einiger Zeit auch gern mal korrupte Arbeitsstände. Dann darf der Entwickler wieder zurück auf LOS ohne einen Erfolg einzustreichen. Wie soll man also die Signale aus dem Hause Oracle deuten? Möglicherweise ist sich Oracle intern selbst uneins und setzt später einfach auf die Technologie die sich durchsetzt. Einige Entwickler greifen daher selbst zur IDE und bauen schon wieder ihre eigenen RIA Frameworks:

Captain Casa Framework

Da ich dieses RIA Dilemma schon einige Zeit betrachte setzte ich immer wieder meine Hoffnung auf das Captain Casa Framework. Captain Casa ist eine Firma welche für den lokalen Mittelstand diverse Softwarelösungen erarbeitet hat. Diese basieren alle auf dem Captain Casa Framework. Diese wiederum setzte bis vor einigen Jahren ausschließlich auf Swing, sprang aber nach Erscheinen von JavaFX sofort auf diesen Zug auf. Aktuell steht wieder ein Community Treffen an und ich hoffe das es mir dieses Jahr endlich wieder möglich ist teilzunehmen und meinem kurzfristigen Urlaubsantrag zugestimmt wird. Falls ja werde ich natürlich wieder über das Treffen berichten.

Anbei ähnliche Artikel zum RIA Dilemma

CC – Singleton korrekt implementieren


Flattr this

Motivation

Seit ich Clean Code [martin2009cleancode] lese, wollte ich das Gelesene auch gleich in meinem Blog posten um mir jenes erworbene Wissen für die Zukunft zu sichern. Leider geht das nicht so einfach, da diverse Punkte durchaus kontrovers diskutiert werden und sich stets auch Alternativen finden, welche nicht unbedingt schlechter sind. Zur Bewertung der Lösungen müssen erst eigene Erfahrungen gesammelt werden. Es genügt nicht zu sagen, es hies immer das wäre eine schlechte Lösung darum habe ich diese nie verwendet. Man muss auch verstehen warum die Lösung schlecht ist. Dazu muss man entweder ein paar Argumente kennen oder Erfahrungen mit der Lösung gesammelt haben oder aber vollständig die Vor- und Nachteile sowie die eigentlichen Ziele im konkreten Fall erfasst haben.

Es gibt Leute die lesen solche Bücher in ein paar Tagen und berufen dann Meetings ein um den Rest der Welt mit dem zu missionieren was sie selbst von dem Buch erfasst haben. In der Regel haben sie einige Dinge falsch verstanden und argumentieren dann vehement gegen die Anderen.

Diesen Fehler wollte ich nicht machen. Deshalb möchte ich auch ausdrücklich darauf hinweisen, dass die Artikel nur gesammeltes Wissen und Erfahrung sind. Keine Garantie, dass die Aussagen stimmen. Letztlich muss jeder selbst darüber nachdenken. In meinen Artikeln kann ich nur Hilfen und Argumente zur Verfügung stellen. Ich kann auch Empfehlungen aussprechen aber entscheiden muss letzlich jeder für sich allein.

Aus diesem Grund halte ich es für das Beste, einzelne Teilprobleme heraus zu greifen und diese von allen Seiten zu beleuchten. Vor- und Nachteile zu diskutieren und dem Leser damit eine Entscheidungshilfe an die Hand zu geben. Entscheiden muss er letztlich immer selbst am realen Kode.

Damit startet die Serie zur Clean Code Programmierung. Für den Leser stets erkennbar am dem CC – vor dem eigentlichen Titel.

Ziel des Singleton Pattern

Manchmal ist es wünschenswert, dass nur exakt eine Instanz von einer Klasse global existiert. Damit kann sich der Programmierer dann darauf verlassen, dass immer wenn Logik dieser Klasse ausgeführt wird, geschieht dies in dieser Einen Instanz. Soweit der Wunsch. In Wirklichkeit greifen im Java Umfeld noch einige Nebenbedingungen auf die wie nebenbei zu sprechen kommen. Diese Aufgabenstellung besitzt eine Lösung, das Singleton Pattern. Beschrieben ist dieses unter anderem in [Gam1994].

Wann ist das Pattern anzuwenden?

In [Gam1994] werden dazu 2 Gründe aufgeführt. Wende das Pattern an wenn:

  1. Du eine Klasse hast von der nur exakt eine Instanz existieren darf und diese soll von Clients zugreifbar sein über einen gut bekannten Zugriffspunkt.
  2. Wenn die Einzige Instanz durch Subklassen erweitert werden soll und ein Client soll in der Lage sein Instanzen von Subklassen zu nutzen ohne ihren Kode zu modifizieren.

Damit beginnt die erste Diskussion! In Java EE Umgebungen wird die Erzeugung von Objekten (Instanzen) dem Container übertragen. Er allein darf darüber entscheiden ob eine, zwei, oder mehr Instanzen einer Klasse zeitgleich existieren sollen. Die Verwendung von Singleton greift damit in die Freiheit des Containers ein. In konkreten Fällen kann damit eine Änderung der Implementierung der Containerlogik behindert werden. Der Architektur wird damit Flexibilität genommen. Der Architekt hatte möglicherweise bereits geplant zunächst einen Pico Container einzusetzen und in der zweiten Phase einen Spring Container. Er rechnet in der Regel nicht mit Entwicklern die ihm hier Steine in den Weg legen indem sie unkontrolliert in die Containerlogik eingreifen.

Sei es drum – wir haben mit unserem Architekten gesprochen und er sieht ein, dass es sein muss. Natürlich mit der Auflage das Pattern so wenig wie möglich zu nutzen. Wann nutzen wir es dann? Wenn die 1. Bedingung erfüllt ist? Wenn die 2. Bedingung erfüllt ist oder nur wenn beide Bedingungen erfüllt sind?

Aus meiner Sicht gibt es keinen Grund in einer Java EE Umgebungen ein Singleton zu verwenden, es sei denn man schreibt ein Framework und keine Anwendung. Aber diese Aussage möchte ich nicht als Lösung stehen lassen, da mir nicht klar ist ob meine Auffasung hier richtig ist. Letztlich läuft es wohl auf Einzelfallentscheidungen heraus.

Singleton – erster Versuch

package de.theserverside.designpatterns.singleton;

/**
* Klassische Implementierung des Singleton-Patterns
*/
public class ClassicSingleton {
private static ClassicSingleton instance = null;

/**
* Default-Konstruktor, der nicht außerhalb dieser Klasse
* aufgerufen werden kann
*/
private ClassicSingleton() {}

/**
* Statische Methode, liefert die einzige Instanz dieser
* Klasse zurück
*/
public static ClassicSingleton getInstance() {
if (instance == null) {
instance = new ClassicSingleton();
}
return instance;
}
}

Quelle: [Singleton]

Prinzipiell wird hier auf lange Sicht immer eine Instanz zurückgegben. Jedoch in der Anfangsphase kann es in Multithread Umgebungen zu Problemen kommen. Wenn der erste Thread in die getInstance() Methode eintritt und die if Anweisung mit dem Vergleich auf null noch passiert, dann jedoch vom System (Container, JVM, OS, …) schlafen gelegt wird. Während Thread 1 träumt, tritt ein zweiter Thread in die getInstance() Methode ein und passiert die if Abfrage welche immernoch true ergibt, erzeugt ein neues Objekt und bevor er dieses der Klassenvariablen zuweisen kann wird auch er ins Koma versetzt. Das Gleiche können jetzt noch hunderte von Threads genauso machen. Irgendwann wacht einer (evtl. der erste Thread) wieder auf und nimmt die Zuweisung auf die Klassenvariable vor. Ab da liefert die if Bedingung false. Jetzt wachen noch die anderen schlafenden Threads auf und nehmen ihrerseits die Zuweisung auf die Klassenvariablen vor. Je nachdem zu welchem Zeitpunkt dann die getInstance() Methode aufgerufen wird liefert sie ein anderes Objekt zurück. Erst ab dem Zeitpunkt ab dem sich kein Thread mehr innerhalb des Bodies der If Anweisung befindet, erst ab da wird stets die selbe Instanz zurückgegeben. Diese Implementierung führt also nicht zum Ziel.

 

Quellennachweis

[martin2009cleancode]
Martin, Robert C.: Clean code: a handbook of agile software craftsmanship. 1. Upper Saddle River, N.J. : Prentice Hall International, 2009. – ISBN 0-13-235088-2
[Gam1994]
Gamma, et al: Design Patterns: Elements of Reusable Object-Oriented Software : Addison Wesley Professional, 1994
[Singleton]
The Server Side Web Site Discussion