Erinnerung: Singletons vermeiden

Heute mal ein Gedanke, der im Grunde keine Erläuterung braucht: Singletons werden fast nie gebraucht und sollten vermieden werden.

Auf den Google-Seiten zur Test-Coverage der Google Update Engine bin ich gerade nochmal auf einen interessanten Link gestoßen, warum Singletons eine schlechte Idee sind: The Singleton Smell, immerhin von Juli 2006, von Greg Miller auf im Unixjunky Blog.

Zusammengefaßt läßt sich sagen: Singletons sind eine Übertragung des Konzeptes globaler Variablen auf OO-Design, was allein schon verdächtig ist, und erschweren bzw. verhindern Unit Tests, da sie die Verwendung von Mock-Objekten erschweren bzw. verhindern.

Im Grunde sollte es immer möglich sein, Singletons zu vermeiden, da ja jedes Programm einen definierten Startpunkt hat, von dem aus Objekte instantiiert und Methoden aufgerufen werden. Problematisch sind wohl nur "magische" Bibliotheken, die zwar technisch initialisiert werden müssen, diese Tatsache in ihrem Interface aber verheimlichen. Mal ein ausgedachtes Beispiel: Eine Bibliothek zur Verschlüsselung benötigt einen Zufallsgenerator, der wiederum mit einem Initialisierungsvektor instantiiert wird. Im Interface der Bibliothek taucht der aber nie auf, sondern wird von der Bibliothek im Hintergrund verwendet. Wenn die Funktionen der Bibliothek jetzt keine Referenz auf eine Bibliotheksinstanz bekommen, müssen sie über ein Singleton den Zufallsgenerator finden.

Warum sollte man jetzt den Zufallsgenerator auslagern? Nun, einerseits kann mit dem versteckten Generator nicht überprüft werden, ob Verschlüsselungsroutinen auch wirklich immer funktionieren, z.B. für besondere Zufallszahlen. Man kann andererseits auch nicht prüfen, ob der Zufallsgenerator hinreichend zufällig arbeitet.

Man kann also nur noch akzeptieren, daß die Bibliothek als Ganzes funktioniert, oder eben sehr lange testen und hoffen, zufällig auf Fehler zu stoßen -- die dann aber nicht mehr reproduzierbar sind. Insgesamt unschön, und nur durch Redesign der Bibliothek korrigierbar, was wieder ein Refactoring aller Applikationen nach sich zieht, die auf der Bibliothek aufbauen. Noch unschöner, und der ausschlaggebende Grund, warum einige Bibliotheken bzw. Frameworks voraussichtlich nie "verbessert" werden.

Schlußfolgerung: Vermeiden, wo es geht, und wo es nicht geht, überlegen, ob es nicht doch geht.

Über Tests, Git und Macs

Gerade stöbere ich so herum, um ein nettes Git-Plugin für mein Xcode zu finden, da stoße ich einen wirklich interessanten Artikel über's Testen, unter dem provokanten Titel Testing is overrated. Na klar, denke ich mir, die Rails-Typen haben sowieso einen Hang dazu, Dinge als overrated abzutun -- oft genug stellt sich hinterher heraus, daß sie Recht hatten (ich erinnere mich an die Aussage "Flexibility is overrated"). Aber ich schweife ab, Fakt ist, der Artikel ist sehr informativ.

Ach ja, ein Git-Plugin habe ich nicht gefunden, aber eine andere Seite zum Thema Git auf dem Mac: Unter Git, iDisk und so schreibt Thomas Dohmke auf mllog eine kleine Einführung zu Git auf dem Mac, inklusive einer cleveren Anwendung für die iDisk, die wir Mac-User ja zum Glück alle haben. Na ja, einige jedenfalls.

Bleibt nur: Wie komme ich im Büro an meine iDisk? Muß ich noch nachdenken.

Apropos Datensicherheit: Meldedaten

Und noch ein Artikel auf heise.de: Sächsischer Städte- und Gemeindetag: Verkauf von Meldedaten ist zulässig. Wir brauchen also keine schmierigen Gangster mit großen Hüten unter einsamen Laternen, die nächtlich DVDs mit massenweisen persönlichen Daten für jede Menge gutes Geld verscherbeln, denn die Städte und Gemeinden tun das ganz einfach per Internet.

Was für eine interessante Entwicklung. Bei der Gelegenheit könnte man doch gleich ein Monopol auf den Verkauf von personenbezogenen Daten einrichten, damit den Städten und Gemeinden dieses Geld nicht mehr entgehen kann. Andererseits: Warum sollte man für einen mittleren fünfstelligen Betrag dubiose Daten aus dubiosen Quellen kaufen, wenn man sie legal für den berühmten Apfel und das Ei bekommt? Vielleicht ist ja auch das die Peinlichkeit: Dresden hat im Jahr 2007 nur knapp 316000 Euro per Adreßhandel erwirtschaftet, für dieses Jahr sind nur 375000 Euro geplant.

Wer bei den Preisen noch klaut ist bescheuert.

Heile Welt und Datenklau

Im Artikel "Jede zweite Rufnummer in den falschen Händen" auf heise.de finde ich gerade einen lustigen Abschnitt:

Gesetzliche Bestimmungen, die den Einsatz etwa von digitalen Markern für die Rückverfolgbarkeit von Daten vorsehen, gebe es schon längst. Wer sich an die Vorschriften halte, könne inzwischen auch bemerken, wenn ein Mitarbeiter sich Zugriff zu größeren Datensätzen verschaffe. Die Defizite lägen eher in der Umsetzung, kritisierte [Thilo] Weichert [Datenschutzbeauftragter von Schleswig-Holstein -- Anm. ketchup].

Nun, das ist ja amüsant. Dazu muß ich sagen, daß ich ein großer Freund von Datenschutz (in beiden möglichen Interpretationen) bin. Allein: Gesetzliche Bestimmungen zu digitalen Markern etc. können nur der Beruhigung des Gewissens dienen, in der Realität taugen die Regelungen nichts: Spätestens im Data Warehouse werden alle Daten aus den ach so sicheren Datenbanken gesaugt und in bunte Bildchen gemanscht. Aber auch sichere Datenbanken sind nicht sicher, weil sie heute nur noch mehr oder weniger dumme Speicher für die Application Server darstellen und nicht mehr feststellen können, wer nun warum auf welche Daten zugegriffen hat.

Der einzig gangbare Ausweg aus der Misere ist tatsächlich Datensparsamkeit: Daten, die ich nicht brauche, werden nicht gespeichert.

Was man nicht hat, kann einem nicht geklaut werden. Alles andere ist Gerede.

Shape of Things to Come?

Rein zufällig stolpere ich heute bei Golem über einen interessanten Artikel: Forscher: Tom-Skype überwacht seine Nutzer. Nun, vielleicht ist ja "interessant" nicht das richtige Wort, vielleicht sollte man eher "beunruhigend" sagen. Und hoffen, daß die ganze China-Begeisterung bestimmte Leute nicht dazu bringt, sich unter das "Von China lernen heißt siegen lernen"-Banner zu stellen.

Git Nachtrag zur Version 1.6.x

Mir fällt gerade noch ein, daß es zur aktuellen Version 1.6.x von Git noch einen Nachtrag für meine Blogeintrag gibt. Also: Scripte umschreiben!

Gutes Essen auf schmalen Straßen?

Um mal einen ebenso einleuchtenden wie nutzlosen Kommentar zum Universum abzugeben und somit der kritischen Masser der Information einen Schritt näher zu kommen (wenn mich meine Erinnerung nicht trügt, hat Stanislav Lem dazu mal eine Kurzgeschichte geschrieben, aber ich finde beim besten Willen nicht heraus, welche es war: Irgendwer hat in einem Supercomputer in Afrika (?) solange irgendwelchen Datenmüll abgeladen, bis die "kritische Masse" von Information überschritten wurde und alle in Computern weltweit gespeicherten Daten verloren gingen, was die Menschheit gehörig zurückwarf...), hier mal zwei Aussagen, über dessen Beziehung untereinander ich gelegentlich eine Studie anzufertigen wäre:

In Italien gibt es gutes Essen. Das Autofahren in Italien ist die Hölle.

Java vs Ruby on Rails... wieder mal

Ist ja eigentlich schon fast langweilig, denn zu dem Thema wurde schon unendlich viel geschrieben. Was ist jetzt besser? Java oder Ruby?

Stratisch typisiert oder dynamisch typisiert? Interpreter oder Compiler? Perl oder Python? C/C++ oder ASP.NET? Linux oder Windows? Das Internet hat eine lange Geschichte erhitzter Debatten, die ebenso vehement geführt wurden, wie sie sinnlos waren und sind, weil eben jede Seite gute Argumente hat (die in diesen Diskussionen allerdings selten vorgebracht werden). Mehr gefällig? Atari oder Amiga? Emacs oder vi? VMS oder Unix?

Aber Pardon the Information's Robert J. Miller hat mit Java vs. Ruby on Rails - Its a Dead Heat einen interessanten Artikel geschrieben, der im ungewöhnlichen, aber vernünftigen (oder gar erwarteten) Fazit gipfelt, daß beide Lösungsansätze Vor- und Nachteile haben, und beide Ansätze schief gehen können. Interessant vor allem die "entrepeneurial report card". Lesenswert.