Sonntag, 9. Juni 2013

Das Uniform Access Prinzip

Name, Kurzform Uniform Access Prinzip
Synonyme
Prinzip des einheitlichen Zugriffs,
Prinzip des gleichartigen Zugriffs,
Uniform Access Principle (UAP)
Beschreibung
„Alle Dienste eines Moduls sollten in einer gleichartigen Notation angeboten werden, die nicht preisgibt, ob es sich um Datenzugriffe oder Berechnungen handelt.“ [Meyer1998]
Erläuterung
Erinnern wir uns: Bertrand Meyers Absicht war es, das Konzept der Modularität (engl. modularity) zu präzisieren, um es als eines der Grundkonzepte der Objektorientierung nutzen zu können. Das UAP ist eines von fünf Prinzipien sowie einigen begleitenden Kriterien und Regeln, die Meyer für Software-Module aufstellt.

Für sich genommen erscheint das UAP heute trivial. Einige Programmiersprachen unterstützen es direkt (Eiffel, Ruby, VisualBasic). In den meistverbreiteten objektorientierten Sprachen (wie Java, C++, C#) ist ein direkter Feldzugriff zwar nicht verboten, das Anlegen von Gettern und Settern ist jedoch geradezu ein Automatismus geworden. Aus Meyers Sicht erscheint allerdings bereits diese Notwendigkeit als Mangel:
„Erstens ist es niemals eine gute Idee, einen Mechanismus in einer Sprache zu verankern und den Leuten dann zu erzählen, dass sie diesen nicht nutzen sollen. (…) Zweitens sind selbst diejenigen, die diesem Ratschlag folgen wollen, auf Funktionen angewiesen, deren einziger Zweck darin besteht, den Wert des jeweiligen Attributs zurückzuliefern. (…). Solche Funktionen sind Rauschen, das den Code sinnlos verlängert.“ [URL:Meyer2005].
Ein Entwickler, der in einer solchen Sprache entwickeln muss, wird von dieser Einsicht allerdings wenig profitieren und um die Accessoren nicht herumkommen.
Beispiel(e)
  • In Eiffel werden sowohl Attribute als auch Methoden als sogenanntes feature deklariert. Aus der Sicht eines Aufrufers ist dabei die Form des Aufrufs immer o.feature für ein Objekt o. In Eiffel besteht daher keine Möglichkeit, gegen das UAP zu verstoßen. Zum feature-Konzept von Eiffel wird in [Meyer1998] die folgende Übersicht gegeben:
  • In Java wird auf Felder mittels o.feldname und auf Methoden mittels o.methodenname() zugegriffen. Dies verstößt grundsätzlich gegen das UAP. Der Entwickler kann diesen Verstoß zumindest vermeiden, indem er auf das Feld immer über eine eigens dafür implementierte Getter-Methode, also mittels o.getFeldname() zugreift.
Historie
  • Bereits die Programmiersprache Algol W, ein Vorschlag von Niklaus Wirth aus dem Jahr 1966, erfüllte das UAP.
  • Bertrand Meyer gibt in [Meyer1998] an, dass das Prinzip ursprünglich unter dem Namen „Uniform Reference“ in [Geschke1975] beschrieben wurde.
  • Erste Versionen von Eiffel entstanden ab 1985.
  • Das Prinzip wurde unter dem heutigen Namen in [Meyer1998] veröffentlicht.
Art des Prinzips
  • Grundlegende Einteilung: Produktprinzip.
  • Technologiebezug: Übergreifend.
  • Entwurfsgüte: Bausteineigenschaft.
  • Handlungsbezug: Erleichterung von Änderung.
  • Kognitionsbezug: Keiner.
(Siehe Kategorisierung der Prinzipien.)
Grad der formalen Spezifikation Hoch. In einigen Programmiersprachen syntaktisch sichergestellt. In anderen zumindest syntaktisch überprüfbar.
Vorteile
  • Präzises Kriterium für die Möglichkeit zur Anwendung modularer Entwurfsprinzipien.
  • Eingebettet in ein detailliertes System weiterer Kriterien, Regeln und Prinzipien.
Nachteile
Trotz der umfangreichen Ausarbeitung erscheint Meyers Fundierung des Modulkonzepts keineswegs alternativlos. Es fehlt ebenso eine mathematisch-formale wie auch eine empirische Rechtfertigung gerade dieser Ausarbeitung.
Übergeordnete Prinzipien
Gemäß Meyer:
Abgleitete Prinzipien Alle Prinzipien, die auf Modulen basieren.
Qualitätsmerkmale (+) Änderbarkeit, (+) Testbarkeit
Quellen
[Geschke1975] - On the Problem of Uniform References to Data Structures, Geschke, C. M., Mitchell, J. G. (1975)
[Meyer1998] - Objekt-oriented Software Construction 2nd Edition, Bertrand Meyer (1998)
Eingestellt von um