fjord

Wer kennt es nicht, nachdem man sich in einem Thema eigentlich ganz gut auskennt und vielleicht auch schon mehr als die ersten Gehversuche hinter sich hat, geht einem bei etwas Grundlegendem ein ganzer Kronenleuchter auf. Das dann folgende Gefühl ist eine Mischung aus Freude, über die Erkenntnis und Zweifeln an der eigenen Intelligenz, weil man sowas Grundlegendes nicht schon früher Begriffen hat.

Von einem solchen Moment möchte ich an dieser Stelle berichten. Seit ca. einem Jahr, bin ich raus aus der Uni und drin im Berufsleben. Dort basteln wir an einer Platine, auf der ein Microcontroller werkelt, einem eingebetteten System, wie man so schön sagt. Da man an der Uni von den sog. Best Practices nur wenig mitbekommt, hab ich mir zwei Bücher geshoppt, von denen sich eins auf eingebettete Systeme und das andere auf reine Programmierung bezieht. In beiden, geht es im Grundsatz darum wie man Dinge macht und warum man sie so macht. Und bei der Lektüre ist mir ein Licht aufgegangen im Bezug auf das Geheimnisprinzip.

An der Uni wurde mir in der Informatikvorlesung die Programmiersprache Java serviert und in diesem Rahmen wurde uns früh begebogen, dass wir das Geheimnisprinzip zu wahren haben. Das hieß hauptsächlich, dass wir vor die Variablen der Attribute in unseren Klassen das Schlüsselwort “private” geschrieben haben. Seit jeher hat sich in meinem Hirn der Gedanke manifestiert, dass das Geheimnisprinzip hauptsächlich aus Sicherheitsgründen wichtig ist. Gleichzeitig fand ich das sonderlich, weil auch wenn andere Klassen innerhalb eines Programms durch “private” nicht direkt auf die Variablen zugreifen konnten, programmierte man doch immer Get-Funktionen, die den Wert dennoch zurück lieferten.

Erst vor ein paar Monaten, bei der Lektüre eines der beiden Bücher – keine Ahnung bei welchem genau – fiel der Groschen. Beim Geheimnisprinzip geht es nicht hauptsächlich um Sicherheit, sondern um Modularität.

Was ich vorher schon verstanden hatte, war, dass man um das Geheimnisprinzip einzuhalten seine Klassen so programmieren musste, dass eine andere Klasse die Innereien nicht einfach lesen kann, sondern über eine Funktion gewissen Informationen anfragen muss. Das beschränkt sich aber nicht auf Java und objektorientierte Sprachen. Auch z.B. in C gibt es z.B. das Schlüsselwort “static”, mit dem man Variablen und Funktionen innerhalb einer Datei (nicht Klasse) vor dem Zugriff aus anderen Dateien schützen kann.

An hardwarenaher Programmierung lässt sich der gewonnene Vorteil gut veranschaulichen. Nehmen wir eine Digitaluhr mit Display. Das Programm enthält dabei sinnvollerweise mehrere Abstraktionsebenen. Auf der unteren ebene befinden sich die Treiber für die verwendete Hardware. Um z.B. Zeichen auf dem Display auszugeben, müssen erst die angeschlossenen Pins des Prozessors als Eingang oder Ausgang programmiert werden. Auch möchte man eine Tabelle Hinterlegen welche Segmente des Displays eingeschaltet werden müssen, um z.B. eine 2 darzustellen. Ziel ist ein Treiber, der die nötigen Pins initialisiert und wenn man ihm eine Uhrzeit übergibt diese auf dem Display darstellt. Von außen betrachtet reichen dafür 2 Funktionen, init() und printTime() könnten sie heißen.

Das aber ist die Sicht von Außen auf den Treiber. Im Inneren deutlich mehr Funktionen geben, z.B. eine um die Datenrichtung der Pins festzulegen, eine um die Ausgabepins auf die richtigen Werte für die Initialisierung des Displays zu setzten, usw. Sorgt man jetzt dafür, dass anderer Code von außen wirklich nur auf die init()- und printTime()-Funktionen zugreifen kann, sprich, man hält sich an das Geheimnisprinzip, ergibt sich extrem modularer Code.

Wechselt man z.B. auf ein Display eines andren Herstellers, dessen Hardware anders angesteuert werden muss, so muss trotzdem nur der Treiber neu geschrieben werden und solange der neue Treiber wieder init() und printTime() zur Verfügung stellt, muss der Übergeordnete Code nicht geändert werden.

Es geht also beim Geheimnisprinzip hauptsächlich darum den Code Modular zu halten, um Teile möglichst Rückwirkungsfrei austauschen zu können. Indirekt führt das wahrscheinlich auch zu mehr Übersicht und zu besserem und besser wartbarem Code und dient somit bestimmt auch der Sicherheit. Hauptgrund dafür ist aber Modularität.

Und ich frage mich immer noch: “Hat uns das wirklich keiner gesagt? Hat man es uns gesagt und ich hab es nicht verstanden und wenn ja, warum?”