jtb.blog

Mal wieder ein schönes Beispiel zum Thema Programmieren an der Uni. Aufgabe war die Implementierung einer HashTable in Java. Schon die Angabe der verschiedenen Modi der HashTable über Strings brachte mich arg zum stauen (wo es doch in Java 5 so schöne Enumerations gibt und man damit sich kostenlos Schutz durch den Compiler erkauft).
Aber das Beste war die Verwendung eines Interfaces. Man bekam ein Interface namens EntryInterface gestellt und musste nun eine Klasse namens Entry unter Verwendung dieses Interfaces implementieren.
Moment – Warum ist der Klassenname Entry vorgegeben?
Wir haben doch eine schön definierte Schnittstelle und die mitgelieferten Testcases können doch einfach diese nutzen. Dank Interface habe ich ja ein Abstraktionslayer, so dass die reelle Implementierung von EntryInterface niemanden außer dem Entwickler der HashTable-Interna interessieren sollte.
Beim näheren Anschauen der Testcases lief dann auf, dass diese eine Instanz von Entry benötigen:


Es hat schon einen guten Grund, warum die HashTable in Java anders implementiert ist. Dort muss man nicht ein Objekt übergeben, sondern direkt Key und Data. Eine Klasse weniger nötig zum Benutzen.
Ein Interface auf eine solche Art zu benutzen ist schon arg komisch. Da gibt es nun wirklich bessere Lösungen..

Nachdem mein Gaming-Rechner mit einem 1GB RAM die ganze Zeit schon leicht am Swappen ist, habe ich mir heute zwei 1GB Riegel gekauft. Dank Dual-Channel mussten es ja gleich wieder zwei Riegel sein und nochmal zweimal 512MB erschien mir ein wenig sinnlos – zumal dann alle RAM-Bänke voll sind. Insbesondere im Hinblick auf den Speicherbedarf zukünftiger Spiele unter Windows Vista.
Jetzt muss ich mal schauen ob ich bei einem Standard XP Pro mit 32bit bleibe oder doch den dauerhaften Sprung auf 64bit wage. Treiber sind mittlerweile besser verfügbar als bei meinem letzten Migrationstest vor einigen Monaten. Insbesondere Creative hat ordentlich aufgeholt.

Beim Einbauen habe ich dann leider gemerkt, dass mein Chipsatzlüfter futsch ist