Das Geheimnisprinzip

Das Geheimnisprinzip gilt heute als allgemein anerkannt, so dass es schwer vorstellbar ist, dass seine Einführung einmal auf Widerstände stieß. Es stellt ein wichtiges Partnerprinzip zur Modularisierung dar, die ohne Geheimnisprinzip zahlreiche Vorteile einbüßen würde.

Name, Kurzform	Geheimnisprinzip
Synonyme	Prinzip der Geheimhaltung, Information Hiding (-Prinzip), Prinzip der Kapselung (engl. encapsulation)
Beschreibung	Außerhalb eines Software-Elements sollen die Interna dieses Elements nicht sichtbar sein.
Erläuterung	Die oben notierte Kurzversion des Geheimnisprinzips bedarf einiger Erläuterung: Um welche Software-Elemente geht es? Welche Eigenschaften sind als Interna aufzufassen? Als Software-Element kommt jede syntaktische oder physikalische Einheit einer Software in Betracht, die Funktionen oder Daten oder beides beherbergt und die über eine öffentliche Zugriffsschnittstelle verfügt. Beispiele solcher Software-Elemente sind Module, Klassen, Komponenten, Bundles, Services, Anwendungen u.v.m. Es sollen insbesondere folgende Eigenschaften solcher Software-Elemente verborgen werden: Eigenschaften mit einer hohen Änderungswahrscheinlichkeit. Eigenschaften, deren Sichtbarkeit nach außen nicht unbedingt erforderlich ist. Das Geheimnisprinzip steht in enger Verwandtschaft mit einigen anderen sehr grundlegenden Prinzipien: Es stellt eine Einschränkung des Prinzips der Modularisierung dar. Durch das Verbergen von Details wird oftmals faktisch eine Abstraktion erreicht (Abstraktionsprinzip).
Beispiel(e)	Programmiersprachen: Beschränkung des Zugriffs auf interne Attribute oder Methoden mittels sogenannter Access-Modifier (wie private, protected usw.). Modularisierungs-Technologie: Explizite Exports für OSGi-Bundles. Entwurf: Blackbox-Reuse mittels Komposition. Gegenbeispiel: „Inheritance breaks encapsulation“
Historie	David Parnas hat zur „Entdeckung“ des Geheimnisprinzips in [Parnas2002] eine amüsante Geschichte erzählt, die zugleich verdeutlicht, dass dieses heute weithin anerkannte Prinzip zunächst durchaus auf den Widerstand von Fachkollegen stieß. Ein Artikel, den Parnas einer Fachzeitschrift zusandte, wurde vom Reviewer mit den Worten „Offensichtlich versteht Parnas nicht wovon er redet, denn niemand tut es auf diese Weise“ zunächst abgelehnt. Als erste Veröffentlichung gilt heute Parnas Artikel „On the Criteria To Be Used in Decomposing Systems into Modules“ [Parnas1972]. Parnas stellt in diesem Artikel zwei Möglichkeiten zur Zerlegung eines angenommenen Beispiel-Systems einander gegenüber: Zerlegung auf der Grundlage eines Flussdiagramms: Die Module werden entsprechend einzelnen Verarbeitungsschritten gebildet. Zerlegung auf der Grundlage von Design-Entscheidungen mit hoher Änderungswahrscheinlichkeit („design decisions which are likely to change“): Die Zerlegung erfolgt hier, um derartige Entscheidungen in den einzelnen Modulen zu verbergen. Bis heute hat sich das Geheimnisprinzip, wie bereits die oben gewählten Beispiele zeigen, in zahlreichen Erscheinungsformen bis in die Syntax von Programmiersprachen und Modularisierungstechnologien verbreitet.
Art des Prinzips	Grundlegende Einteilung: Produktprinzip. Technologiebezug: Allgemeingültig. Entwurfsgüte: Zerlegungsprinzip. Handlungsbezug: Erleichterung von Änderung, Wiederverwendung und Verstehen. Kognitionsbezug: Komplexitätsreduktion, Abstraktion. (Siehe Kategorisierung der Prinzipien.)
Grad der formalen Spezifikation	Im Falle syntaktischer Unterstützung in folgender Hinsicht hoch: Die verborgenen Systemteile können syntaktisch festgestellt werden. Verstöße gegen das Geheimnisprinzip werden auf diese Weise bereits zur Kompilierzeit festgestellt. Weniger gut formalisierbar sind folgende Aspekte: Die Erkennung von System-Elementen, die unnötigerweise nicht verborgen wurden, ist schwierig. Die Gruppierung von Elementen an Hand von Änderungserwartungen kann ebenfalls nicht formal überprüft werden.
Vorteile	Einfach verständlich. Fördert zahlreiche Qualitätsmerkmale. Macht Modularisierung erst wirkungsvoll.
Nachteile	Basiert auf Änderungserwartungen und ist in dieser Hinsicht von Annahmen über künftige Entwicklungen abhängig. Erfordert Erfahrung und Weitsicht beim Schnittstellen-Entwurf.
Übergeordnete Prinzipien	Modularisierungsprinzip. Abstraktionsprinzip Prinzip der Änderungsnotwendigkeit
Abgleitete Prinzipien	-
Qualitätsmerkmale	(+) Komplexität, (+) Änderbarkeit, (+) Testbarkeit, (+) Wiederverwendbarkeit, (+) Verständlichkeit, (+) Zuverlässigkeit

Quellen  

[Parnas1972] – On the Criteria To Be Used in Decomposing Systems into Modules, David L. Parnas, in: Communications of the ACM, 1972

[Parnas2002] – Software Pioneers, Hrsg. M. Broy und E. Denert, Kapitel The Secret History of Information Hiding (ab Seite 399), David L. Parnas, 2002