Software Engineering

Informatik Hartmut Härtl

Geheimnisprinzip

Dieses Prinzip dient vor allem der Verringerung von Fehlerquellen bei der Entwicklung modularisierter Softwaresysteme. Bei solchen System werden die Entwickler leicht dazu verleitet, ihre Programmierung dadurch zu "verbessern/vereinfachen", indem sie der Einfachheit halber über die dokumentierten Schnittstellen hinaus Implementierungsdetails der benutzten Module einbeziehen, die nicht zur öffentlichen Spezifikation der benutzten Module gehören.

Zunächst scheint dies besonders vorteilhaft zu sein. Die Erfahrung zeigt aber, dass gerade dadurch die Wurzeln für später kaum mehr nachzuvollziehende Fehler bei späteren Softwareänderungen gelegt werden. Um solche "verborgenen Schleichwege" von vornherein zu verhindern, verlangt das Geheimnisprinzip, dass dem Benutzer einer Abstraktion, wie z.B. eines Klassenmoduls, alle implementierungsbezogenen Interna verborgen bleiben sollen. Umgekehrt kann man auch formulieren, dass alle Angaben, die zur Benutzung eines Moduls nicht erforderlich sind, auch nicht nach außen sichtbar sein sollen.

So stellt das Geheimnisprinzips sicher, dass eine Abstraktion, wie z.B. eine Klasse, nur im vorgesehenen Sinne verwendet werden kann. Die Wahrung dieses Prinzips fördert besonders folgende Eigenschaften:

  • Die Konsistenz (Widerspruchsfreiheit) interner Daten kann besser sichergestellt werden, da auf diese nur ein kontrollierter Zugriff über speziell dafür vorgesehenen Methoden möglich ist.

  • Der Anwender einer Abstraktion wird nicht mit unnötigen Informationen belastet.

  • Solange die Schnittstellen (Syntax und Semantik) nicht betroffen sind, können Implementierungsdetails der entsprechenden Module beliebig oft geändert werden, ohne dass andere Programmteile betroffen sind. (Verbesserung der Änderbarkeit/Wartbarkeit)

Bei der OOP erhält das Geheimnisprinzip durch das Prinzip der Kapselung seine besondere Ausprägung. Kapselung bedeutet, dass auf die Attribute eines Objektes nur kontrolliert über die entsprechenden Methoden zugegriffen werden kann. (Alle Attribute sind grundsätzlich als "private" deklariert.)

Bei der Implementierung von Modulen

Nach außen sind grundsätzlich nur definierte Methoden sichtbar. Auf die Attribute eines Objektes kann nur über die entsprechenden Methoden wie z.B. "set- und get-Methoden" zugegriffen werden. (Strikte Kapselung.)

Völlig falsch und gefährlich wäre es, z.B. innerhalb der Klasse "TListe" das Attribut "Listenlaenge" der Einfachheit halber "public" zu deklarieren, um sich so eine besondere "get-Methode" zu ersparen. Dadurch wäre es jedem Modulbenutzer möglich die aktuelle Listenlaenge unkontrolliert auf jeden beliebigen "Schrottwert" zu verändern.

Grundsätzlich gilt :

  • Alle Attribute einer Klasse sind grundsätzlich "private".

Nur wenn es unumgänglich ist, wird ein Attribut der zu implementierenden Klasse als Variablenparameter an eine "fremde" Methode übergeben. Dies ist ggf. in der entsprechenden Spezifikation ausdrücklich hervorzuheben.

 

Bei der Benutzung von Modulen

Jeder Entwickler und jede Entwicklerin, der/die ein Modul benutzt, darf dieses nur über die in der Exportschnittstelle vorgesehene Art und Weise tun. Es ist ein schwerer Verstoß gegen das Geheimnisprinzip, wenn der Benutzer eines Moduls auf Grund seiner speziellen Kenntnisse über die Realisierung der jeweiligen Datenobjekte oder Algorithmen diese Details unmittelbar bei der Lösung seiner Probleme "ausschlachtet". Eine spätere Wartung oder Änderung der Implementierung kann dann zu völlig undurchsichtigen Nebeneffekten führen.

Hat der jeweilige Entwickler das Modul selbst erstellt, so fällt ihm die Einhaltung dieses Prinzips sicherlich besonders schwer, da er ja alle Implementierungsdetails in- und auswendig kennt.

Er ist hier ständig einem Rollenwechsel unterworfen. Bei allen Algorithmen die er innerhalb seines Moduls implementiert darf er selbstverständlich auf alle internen Details dieses Moduls zurückgreifen. Benutzt er dabei Funktionen aus einem anderen Modul, so darf er insoweit nur noch solche Informationen in seine Überlegungen einbeziehen, die zur Schnittstelle der jeweiligen Methode veröffentlicht wurden.

Weiß z.B. der Programmierer, dass die Methode "setDate" einer Klasse "TDatum" bei der gegebenen Implementierung ohnehin intern die beiden ersten Stellen der Jahreszahl abschneidet und programmiert deshalb seinen Teil so, dass er deshalb an dieser Stelle der Einfachheit halber immer nur die beiden letzten Stellen der Jahreszahl übergibt, so mag das zunächst effizient erscheinen. Spätestens aber dann, wenn das Jahr-2000-Problem in der Klasse "TDatum" zentral gelöst wird, werden sich alle wundern.

 

zum Seitenanfang springen

zum Seitenanfang springen