Intuitive Namensgebung und Länge von Namen im (Java-)Code

Als Softwareentwickler stehen wir des Öfteren vor dem Problem, einen Namen für eine Klasse, eine Methode oder eine Variable zu finden. Bei dieser doch sehr alltäglichen Arbeit kann man aber schon viele Fehler begehen. Sind schlecht gewählte Bezeichnungen doch schnell irreführend und damit nicht gerade intuitiv verstehbar. Doch gerade bei der Softwareentwicklung ist Intuition und die adäquate Wahl eines „guten“ Namens wichtig. Schließlich „lebt“ eine solche Software meistens einige Jahre bis Jahrzehnte. Gerade im Enterprise-Umfeld muss eine Software auch nach fünf Jahren noch wartbar sein. Aber auch das private Heimprojekt sollte so gestaltet sein, dass man nach einem halben Jahr noch die Hauptfunktionen durch einfaches Lesen im Code herausfinden kann. Hier sind intuitive Namen das A und O! Weiterlesen

Werbung

Entwicklung eines Browserspiels mit Java

Seit einigen Jahren ist die Welt der Computer-Spiele um eine Nische reicher. Es handelt sich dabei um Spiele, die im Browser gespielt werden und daher auch den Namen „Browserspiele“ tragen. Es gibt wahrscheinlich kaum einen Internet-Nutzer, der nicht wenigstens kurz eines dieser Spiele ausprobiert hat und somit eine ungefähre Ahnung davon hat, wie sie aussehen. In diesem Beitrag geht es jedoch nicht um das, was jeder sieht, sondern um das „Verborgene“: die Serverseite der Browserspiele.

Am Beispiel des Browserspiels „FMO“, das die Welt der Fussball Manager simuliert, stelle ich einen möglichen Systemaufbau der Browserspiele dar und gehe dabei auch auf die jeweils eingesetzten Java-Technologien ein. Auf der Client-Seite stellen die Browserspiele keine großen Anforderungen an die Hardware und Software der User. Jeder
Rechner, der über einen Browser verfügt, und das sind so gut wie alle, kann zum Spielen eingesetzt werden.

Auf der Serverseite muss das System jedoch etwas ernsteren Anforderungen genügen. Es muss mit Tausenden gleichzeitig laufenden Sitzungen umgehen können und stets eine gute Performance abliefern. Erreicht wird dies durch die Skalierung.

Die Skalierung

Die FMO-User gehören jeweils einer bestimmten Spielwelt an, die über eine eigene Hardware verfügt und auf der jeweils eine Instanz der Spiellogik, bestehend aus mehreren Modulen, läuft. Kommt eine Spielwelt an die Grenzen ihrer Leistung, so wird eine neue Spielwelt gestartet, die wiederum über ihre eigene Hardware mit der
entsprechenden Logik darauf verfügt. Auf diese Weise kann das System horizontal uneingeschränkt skalieren. Einige bestimmte Anforderungen trüben jedoch dieses perfekte Bild. Dazu gehören

  • der zentral organisierte Authentifizierungsdienst
  • der zentral organisierte Bezahldienst
  • die Anforderung der Suchmaschinenfreundlichkeit

Um diesen Anforderungen gerecht zu werden wird ein zusätzlicher zentraler Server eingesetzt, der seine spezifischen Aufgaben mittels der entsprechenden Module erfüllt und ansonsten die ankommenden Anfragen an den jeweils zuständigen Server, für User völlig transparent, weiterleitet. Leider stellt der zentraler Server auf diese Weise einen Flaschenhals dar. Um dieses Problem zu
mildern kann jedoch ein Loadbalancer eingesetzt werden.

Die Schichten-Architektur

Das FMO-System basiert auf einer Vier-Schichten-Architektur. Die Geschäftslogik des Spiels wird in mehreren eigenständigen Komponenten abgebildet. Diese laufen als eigenständige Prozesse und
können von der Präsentationsschicht sowie anderen Geschäftskomponenten angesprochen werden. Zur Datenspeicherung nutzen sie die darunter liegende Persistenzschicht. Oberhalb der Geschäftslogik ist die WebApp-Schicht angesiedelt. Die Web-Apps bedienen die Anfragen der Web-Clients (Browser) und greift während der Verarbeitung der Anfragen auf die Dienste der Geschäftskomponenten zurück.

Schließlich ist im Browser der Spieler die vierte Schicht des Systems angesiedelt. Sie ist für die grafische Repräsentation verantwortlich und besteht aus den JavaScript- und HTML-Modulen, die
mittels der AJAX-Anfragen über HTTP mit den Web-Apps kommunizieren.

Die Java-Technologien

Die Geschäftslogik und weite Teile der Präsentations-Logik bilden den Kern des FMO-Systems. Beide Schichten sind mittels der Java-Technologien, -Frameworks und -Bibliotheken aufgebaut.

Die Komponenten der Geschäftslogik sind reine Java-Komponenten. Hier werden z.B. die Fussball-Spiele berechnet, das Training simuliert und die finanztechnischen Prozesse abgewickelt. Die nach fachlichen Gesichtspunkten gebildete Komponenten laufen als eigenständige Prozesse, nehmen Anfragen per RMI entgegen und lassen ihre Daten von der Persistenzschicht verwalten.

Die Persistenzschicht arbeitet sowohl mit dem Dateisystem als auch mit einem relationalen Datenbanksystem. Im ersten Fall werden die Daten im XML-Format gespeichert. Zur Umwandlung der in XML vorliegenden Daten zu Java-Objekten und vice versa wird die Java-Bibliothek XStream eingesetzt. Der Zugriff auf die Datenbank erfolgt per JDBC. Zur Abbildung der relationalen Daten auf der Objektebene wird außerdem auf das O/R-Tool Hibernate zurückgegriffen.

Die Web-Apps des Systems basieren auf der Servlet-Technologie und laufen in einem Servlet-Container (Tomcat). Der Datenaustausch zwischen den beiden Teilen der Präsentationsschicht (Browser- und Web-Apps) erfolgt mittels der AJAX-Technologie. Dabei wird auf die Hilfe der JSON-RPC Bibliothek jabsorb zurückgegriffen.

Fazit

Java als Programmiersprache mit den entsprechenden Frameworks und Bibliotheken hat sich bei der Entwicklung des Browserspiels „FMO Fussball Manager“ als eine sehr gute Wahl erwiesen. Sowohl in der Entwicklungs- als auch in der Betriebsphase konnten die Anforderungen problemlos erfüllt werden. Java kann daher zum Einsatz in den Projekten zur Entwicklung von browserbasierten Spielen bedingungslos empfohlen werden.

Steckbrief des Autors: Alexander Zent ist selbständiger Software-Entwickler. Er entwickelt und betreibt das Browserspiel FMO Fussball Manager.

[Java] LRU Cache mit Hilfe einer LinkedHashMap

Oftmals benötigt man als Java-Entwickler eine kleine, feine Cache-Klasse, um verschiedene Objekte zwischenzuspeichern und die Datenbank zu schonen. Oftmals wird dann selber mit Arrays, Maps und Listen rumgefuchtelt. Viele kennen nämlich gar nicht die praktische Klasse java.util.LinkedHashMap.

Dabei ist es mit Hilfe dieser Klasse extrem einfach, einen sogenannten LRU-Cache aufzubauen, also einen Least-Recently-Used-Cache. Sprich einen Cache, der die n letzten Objekte speichert. Man gibt also eine feste Cachegröße vor, zum Beispiel 100 und der Cache sorgt dann selber dafür, das Objekte mit einer hohen Zugriffsanzahl weiterhin gecached bleiben und Objekte mit wenigen Zugriffen aus dem Cache entfernt werden. Altes fliegt also nach hinten raus, in dem Fall wenn es mehr als 100 Elemente sind.

Christian d’Heureuse hat dazu jetzt auf Basis der genannten Klasse einen Cache geschrieben, den ich selber leicht abgewandelt so schon benutzt habe. Auf seiner Seite source-code.biz findet sich der entsprechende Source-Code (als ZIP herunterladen) dazu. BTW: Der Trick daraus einen LRU Cache zu machen, ist das Überschreiben der Methode removeEldestEntry der Klasse LinkedHashMap. Damit hat man einen relativ performanten Cache, ohne selber Iterationen einbauen zu müssen, um ggf. veraltete Elemente zu erkennen.

Eine echt praktische Klasse die einem mit Java-Standard-Mitteln eine nette kleine Caching-Funktion bietet.

[JavaScript] Browserfenster im Internet Explorer (IE) ohne Warnmeldung schließen

Es kommt des öfteren mal vor, dass man im Internet Explorer oder jedem beliebigen anderen Browser ein Fenster automatisch via JavaScript schließen möchte. Normalerweise ist das mit einem simplen window.close() getan. Nicht so jedoch im aktuellen IE. Dort poppt dann eine Warnmeldung hoch, die den Anwender nochmals explizit zur Schließung des Fensters befragt. Möchte man dies nicht, kann man das durch einen sehr simplen Trick umgehen und das Fenster schließt sich ohne Warnmeldung sofort.

Ergänzt man einen „leeren“ open() Aufruf, so schließt der IE das Fenster ohne Murren:

<html>
<head>
	<script type="text/javascript">
		window.open('', '_parent', '');
		window.close();
	</script>
</head>
<body>
	Das ist ein Test...
</body>
</html>

Lässt man den Aufruf window.open(“, ‚_parent‘, “); weg, so erscheint wieder die oben dargestellte Meldung. Eine einfache aber auch schlecht verständliche Lösung, also das Dokumentieren nicht vergessen!

[Java] Cross-Platform Compatibility in der Realität

Java ist eine objektorientierte Programmiersprache die getreu dem Motto „write once, run everywhere“ (frei übersetzt: einmal schreiben, überall nutzen) genutzt wird. Gerade diese Stärke wird oft als Vorteil von Java genannt (und ist definitiv auch einer!), man muss jedoch bei einigen Dingen vorsichtig sein, denn oft kann es auch dazu kommen, das aus dem gut gemeinten Motto eher so etwas wird: „write once, debug everywhere“. Da man genau dies natürlich vermeiden möchte, sollte man die folgenden Hinweise beachten:

  • Man sollte sich nicht auf die Groß-/Kleinschreibung eines Systems verlassen (case (in)sensitivity), gerade Windows und Linux sind da unterschiedlich.
  • Man darf sich nicht auf den Pfad-Seperator (Tipp) verlassen, ob das nun ein Slash (/) oder ein Backslash (\) ist, ist vorher nicht immer ganz klar.
  • Ebenso darf man sich nicht auf das Zeilenende (\n vs. \n\r) verlassen, auch hier sind Windows und Linux unterschiedlich.
  • Das Standard-Encoding (UTF-8 vs. CP-1252) ist auf fast jeder Plattform anders, darauf sollte man sich also nicht verlassen.
  • Verwende keine Programmaufrufe wie „cmd.exe“, außer man legt sich zu 100% auf Windows fest.
  • Verlasse dich nicht auf Pfad-Prefixe wie \\ oder C:\.
  • Nutze keine betriebssystem-spezifischen Tastaturbelegungen wie die Windows-Taste.
  • Achte auf die JVM in der das Programm läuft, com.sun.* ist nicht überall verfügbar.

Die Liste ist nicht zu 100% vollständig, deckt aber die häufigsten Probleme auf. Kennt ihr noch weitere? Worauf muss man noch achten, wenn man für verschiedenen Plattformen entwickelt?

Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu. Weitere Informationen zum Datenschutz...

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen