Ein wichtiger Aspekt der letzten Jahre, während der ich mit den UC4 Java API arbeitete, war es, Bausteine für Anwendungen zu entwickeln (und zu erhalten), welche "out of the box" bei unterschiedlichen Kunden lauffähig sind.

Hierbei hat es sich gezeigt, daß neben Klassen für Standardvorgänge wie Connect, Logging oder Cleanup vor allem Klassen für den Zugriff auf UC4 Funktionalitäten hilfreich sind. Zu solchen Funktionalitäten gehören bspw. Zugriffe auf UC4 Objekte wie JOBS, SCRI oder ähnliches, aber auch Zugriffe auf generische Informationen wie die Systemübersicht oder Statistiken. Die großen Vorteile, bei solchen Zugriffen vorhandene Bausteine verwenden zu können, sind

• die Bausteine sind bewährt und ausgereift, Fehler und Abbrüche treten deutlich seltener auf. Dies betrifft nicht nur die verwendeten Klassen für sich, sondern auch deren Zusammenspiel.
• mit Hilfe der Bausteine lassen sich viele Aufgaben sprichwörtlich "on the fly" lösen. Mittelkomplexe Aufgaben lassen sich so in bisweilen gerade einmal einem Tag zufriedenstellend lösen.
• Außerdem wachsen die Bausteine im Laufe der Zeit: sie werden um einzelne Funktionen erweitert, die ihrerseits wieder die Umsetzung anderer Aufgaben deutlich vereinfachen. So ein Feature ist eigentlich trivial; es ist aber immer wieder erstaunlich, wie sich mit solche einfachen Erweiterungen eines Bausteines Aufgaben lösen lassen, die vorher auf Grund des zeitlichen Aufwand für die Umsetzung zurücgestellt wurden.

Die Klassen, die in diesem "Reifeprozeß" entstehen, sind schlank, ohne dabei in ihrer Funktionalität beschränkt zu sein. Sofern der Zugriff auf andere Java Komponenten erforderlich ist (bspw. für Logging, Konfiguration u.ä), werden nur Standardschnittstellen verwendet. Ein defensiver Programmierstil versucht zudem Fehler dort abzufangen, wo sie entstehen, und nicht sie einfach blind "noch oben" weiterzureichen. Erfolg oder Fehler eines Aufrufes werden durch entsprechende Rückgabewerte der aifgerufenen Methoden zurückgeliefert.