Wichtiges Prinzip im objektorientierten Programmieren ist die
data encapsulation:
- Datenelemente
(= Member–Variables) einer Klasse sind als
private deklariert
-
nur
Member–Funktionen der Klasse haben direkt Zugang
- von aussen (Anwendungsprogramm) nur über definierte Schnittstellen (= dedizierte
Member–Functions), z.B. bei
My3Vector–Klasse Koordinaten setzen nur via
Konstruktor beim Erzeugen des Objektes
und Koordinaten lesen via
X(), Y(), Z() Member–Funktionen.
Nachteile (im Vergleich zum
public Zugang):
- Mehraufwand beim Implementieren
X(), Y(), Z() nötig
- Umständlicher in der Handhabung: My3Vector wird beim Erzeugen festgelegt
(Abhilfe: zusätzliche setX(..), setY(..), .. Methoden einführen)
- Performance–Nachteile: Aufruf von Funktion
v.X() dauert länger als
direkter Zugriff
v.x
Vorteile
- Zugang nur über wohldefinierte Schnittstellen
- unabhängig von spezifischer Implementierung
- grundlegendes OO Konzept: Klassen spezifiziert über
Verhalten (Was?), nicht die
Implementation (Wie?)
- erlaubt flexible Änderung/Optimierung der Implementierung –
unabhängig von
Anwendungsprogrammen. 2 Beispiele zu Dreier–Vektor:
- Flexible Wahl der internen Darstellung:
kartesische Koordinaten, Kugelkoordinaten, Zylinderkoordinaten
Implementierung der Methoden muss jeweils angepasst werden, aber keine
Änderung bei
Deklaration/Aufruf
- Alternativ Erweiterung der Member–Variablen um Element
double Laenge, wird bei
Anlegen im Konstruktor berechnet
Optimierung der rechen-intensiven Length()–Methode.
Data encapsulation ist OO-Prinzip aber kein Dogma. Data–members i.a.
private
aber in manchen Fällen
public access durchaus vorzuziehen.