myBlog

Beim Arbeiten bin ich auf etwas gestoßen, das wahrscheinlich irgendwo schon einen tollen Namen hat, ich ihn jedoch noch nicht gefunden habe …

Also, ich schrieb für ein paar Services einfachere zu verwendende Commands. Diese bekamen ein Konfigurationsobjekt das Daten für den Command vorhalten sollte. Beim Erstellen des Commandinterfaces wollte ich beide Methoden (execute und setConfig) in das Interface packen. Doch sollte eigentlich das Ausführen und das Konfigurieren unabhängig von einander passieren. Würden nun beide Methoden im Interface enthalten sein, besteht eine kleine Unsauberkeit, man könnte beim Ausführen die Konfiguration überschreiben.

ist ein weiteres Pattern, das mir in der letzten Zeit immer häufiger über den Weg gelaufen ist. Ansich ist es gar keine schlechte Sache. Was genau ein solches Fluent Interface ist, zeigt das folgende Codebeispiel:
Interface:

interface FluentPerson {
	FluentPerson setAddress(Address address);
	Address getAddress();
	FluentPerson setFirstName(String firstName);
	String getFirstName();
	FluentPerson setLastName(String lastName);
	String getLastName();
}

Class

class PersonImpl implements FluentPerson {
	private Address address;
	private String firstName;
	private String lastName;
 
	public FluentPerson setAddress(Address address) {
		this.address = address;
		return this;
	}
 
	public Address getAddress() {
		return this.address;
	}
 
	public FluentPerson setFirstName(String firstName) {
		this.firstName = firstName;
                return this;
	}
 
	public String getFirstName() {
		return this.firstName;
	}
 
	public FluentPerson setLastName(String lastName) {
		this.lastName = lastName;
                return this;
	}
 
	public String getLastName() {
		return this.lastName;
	}
}

Diese “fast”-Bean-Klasse unterscheidet sich eben darin, dass die Setter der Klasse einen Rückgabewert auf sich selbst hat. Das erlaubt beim Setzen der Adresse ein direktes Zugreifen auf die weiteren Klassenattribute der Person-Klasse. Das FluentInterface erlaubt eine sogenannte MethodChain um die Klassenattribute “fießend” zu setzen.

Ich habe mich auf der Arbeit ja schon mit Spring, speziell mit Dependency Injections, beschäftigt und auch eingesetzt. Die Grundzüge der Dependency Injection sind einfach in vielen Situationen sehr hilfreich. Durch die Definition der Objekte in xml-Dateien, erreicht man eine sehr hohe Flexibilität, die auch zur Laufzeit, ohne den Code anzufassen, angepasst werden kann.

Wie Beans definiert werden können, habe ich hier mal an einem kleinen Beispiel aufgeführt
Listing 1

Da mein jüngerer Brunder Simon nun auch in seinem Studium “programmieren” muss, nahmen wir uns etwas Zeit und ich versuchte ihm grob zu erklären, was es so mit Klassen auf sich hat. In ihrer Informatikvorlesung wird als Sprache Java verwendet, um hier gleich mal die Richtung zu geben, auf welcher Ebene wir uns bewegen, wenn ich am Anfang mit Klassen beginne. Also zeigte ich ihm, was alles so zu einer normalen Klasse so gehört. Da gibt es einen Konstruktor, verschiedene Methoden und Klassenattribute. Nachdem auch erklärt wurde, wie man diese Klasse benutzen kann, sagte ich ihm, er solle einen kleinen Taschenrechner implementieren, der addieren und subtrahieren kann. Mit etwas Unterstützung war auch der Einsatzt von Rückgabewerten der Methoden verstanden

Der Name FindBugs beschreibt nur die Hälfte von dem was es eigentlich kann. Neben dem Erkennen von potentiellen Fehlern schlägt es auch Verbesserungen und Optimierungen des bestehenden Java Codes vor. Diese Tool wird von der Universität Maryland zur Verfügung gestellt und unterstützt das JRE oder JDK ab der Version 1.5. Neben dieser Standalone Version gibt es auch ein Eclipse-Plugin. Möchte man sich jedoch unter Eclipse die View FindBugs-Explorer anzeigen lassen, herrscht gähnende Leere. Die Ursache ist wohl die Null-Pointer-Exception, die nach dem Durchsuchen mit FindBugs des Projekts aufpoppt.