OOP Datenkapselung vs. Information Hiding

[knowledge]

Hallo,

bin grad etwas verwirrt. Einerseits scheinen die Begriffe Datenkapselung und Geheimnisprinzip äquivalent verwendet zu werden, andererseits gibt es da wohl doch ein paar Unterschiede. Die Modifier (private, public) usw. nutz ich doch um die Implementierung zu verstecken. Das wird i.d.R. doch als Datenkapselung betrachtet. Wer kann man auf die Begrifflichen unterschiede eingehen

 

[SlaterB]

Als Datenkapselung (englisch: encapsulation, nach David Parnas auch bekannt als information hiding) [..]

Datenkapselung (Programmierung) ? Wikipedia

 

[knowledge]

Ja, das hab ich auch gelesen. Das wäre eine Quelle die sagt Datenkapselung = Information hiding. Es gibt aber auch etliche andere die da einen Unterschied sehen. Ich weiß nicht ob das nur im englischsprachigen Raum ist, aber da gabs mal nen Artikel Encapsulation is not information hiding

 

[SlaterB]

nun ja, der bzw. ein solcher Artikel ist ja auch schnell gefunden, auf 10 Seiten werden da alle semantischen Details durchleuchtet,
was kann man da noch mehr beitragen?
aber ok, ich schweige einfach und wer was zu sagen hat wird sich schon melden

 

[maki]

Kapselung ist nicht dasselbe wie Information Hiding.
Sie werden zwar manchmal durch ein und dasselben Aktion erreicht, aber nciht immer.

Kurz: Accessoren (Getter, Setter) setzen Informationhiding um, aber nicht immer notwendigerweise auch Kapselung.

Beispiel: Du hast eine Klasse A mit einer Methode die ein Date oder Collection zurückgibt, beide sind Mutable und könnten so vom Aufrufer verändert werden, diese Änderungen wären auch im Objekt der Klasse A sofort sichtbar, ein interner Zustand wurde von aussen verändert, keine Kapselung.

 

[SlaterB]

nicht dass ich wirklich was dagegen hätte, aber um mal etwas genauer reinzugehen:
welche Information soll denn durch die getter + setter versteckt werden? dass die Daten da sind? wohl kaum, Ziel nicht erreicht,
interner Berechnungscode? der ist immer versteckt, kann sowieso nie von außen gesehen werden,
wenn die getter gar keine Klassenattribute sondern neu berechnete Werte zurückgeben, dann ist da durchaus etwas versteckt und gleichzeitig kein Kapsel-Fehler wie du ihn beschreibst

eine Art von Informationhiding ist die Struktur, wie die Nutzdaten intern abgelegt werden, z.B. in ArrayList im Vergleich zu LinkedList,
da geht es Hand in Hand, dass die Implementierung unbekannt ist und die Linked-Entrys bzw. das interne Array nicht nach außen gegeben wird,
gäbe es die getter + setter dazu, wäre die Kapselung nach deiner Definition verletzt, aber auch das Informationhiding weg, denn die Information, dass ein Array oder eine Verlinkung benutzt wird, ist doch offen?

Informationhiding besagt, dass der interne Aufbau einer Klasse oder von mir aus auch nur einer Teilfunktion davon, einer Methode, komplett ausgetauscht werden kann ohne dass das restliche Programm etwas davon mitbekommt,
wie kann sowas umgesetzt werden wenn von außen der interne Zustand veränderbar ist?
dieser Kapsel-Fehler schließt meiner Meinung nach auch Informationhiding aus, zumindest ein gewisser Teil davon in der Klasse,
gewisse Dinge sind dann eben nicht unabhängig und beliebig austauschbar,
während andere Methoden von den geänderten Zustand wiederum unabhängig sind und dennoch geändert werden können

Berechnungscode ist immer versteckt, dafür braucht es kein Pattern/Prinzip,
nur Datenstrukturen, verwendete Subkomponenten, Konfigurationsparameter usw. sind Informationhiding und das klappt doch nur (beliebig austauschbar) wenn sie auch gleichzeitig gekapselt sind?

so, paar Gedanken halb ausgedacht halb aus Links bestätigt, ist was falsches dran?

 

[maki]

Informationhiding besagt, dass der interne Aufbau einer Klasse oder von mir aus auch nur einer Teilfunktion davon, einer Methode, komplett ausgetauscht werden kann ohne dass das restliche Programm etwas davon mitbekommt,

Ganz genau. der interne Aufbau der Klasse bleibt "geheim".

wie kann sowas umgesetzt werden wenn von außen der interne Zustand veränderbar ist?

Schwierige Frage.

Deine Gedanken sind nicht falsch sondern sehr richtig, aber Information Hiding und Kapselung sind trotzdem nciht dasselbe.

Nehmen wir das Trainwreck als Beispiel:
[c]objektA.getB().getC().getD().doSomething();[/c]
Das Problem hier ist unabhängig davon, ob a, b, c oder d mutable sind.
Das Problem ist schlicht, dass alle Aufrufer der Klasse "weiss" das Objekt a ein Objekt b beinhaltet und dieses wiederum ein Objekt c, dieses Wissen ist hardcodiert.
Damit sind die Abhängigkeiten zwischen dem Client und a, b, c & d sehr groß, kein Information Hiding, u.U. aber Kapselung (falls immutable).

 

[knowledge]

@maki

Was für ein Trainwreck Bsp.? Ich hab den Unterschied trotzdem noch nicht ganz verstanden.

public class Mensch() {
String name;

public String getName() { return name; }

}

Wäre das Kapselung von Name aber kein Information hiding? Wenn ich private String name dann Information hiding? D.h. Kapselung + private modifier = Information hiding oder wie ist das zu verstehen?

 

[fastjack]

"Information Hiding" ist ein Pattern von David L. Parnas und stammt aus den 70érn. Es ging darum, "Module" (tja, damals war der Jargon so ) so zu entwerfen, daß verwendete Datenstrukturen vor dem Benutzer verborgen bleiben. Zugriff und Manipualtionen sollen nur über spezielle Methoden möglich sein. Die Verallgemeinerung davon sieht auch die Auftrennung von "Modulen" in Implementation und Schnittstelle, wie das in Modula sehr schön gemacht wurde, um vor dem Benutzer Implementierungsdetails zu verbergen.
In Java hätte man Zugriffs/manipulationsmethoden (auch Getter / Setter) und Schnittstellen/Implementierungen.

 

[fastjack]

Im Prinzip hat Wiki schon recht, es fehlt aber meiner Meinung nach noch eine Verallgemeinerung auf Modulbene. Das wird dort nur ganz kurz bei der Testbarkeit erwähnt, obwohl sie schon ganz zum Anfang erkannt haben, das es sich dabei um ein Konzept aus der strukturierten/modularen Programmierung handelt.