Diskussion:Datenkapselung (Programmierung)

Die Kapselung laut Cisco-Osi-Modell

Die Kapselung laut Cisco-Osi-Modell wäre schön!193.170.118.199 09:08, 19. Apr 2006 (CEST)

• Update* Sollte man für das Schlüsselwort package nicht die Schlüsselwörter in den jeweiligen Sprachen hinzufügen? e86 23:39, 30. Apr 2006 (CEST)

Die Kapselung laut Cisco-Osi-Modell findet man nötigenfalls in der englischsprachigen Wikipedia. (nicht signierter Beitrag von 212.18.1.82 (Diskussion) 18:01, 22. Mai. 2006 (CEST))

Klassen statt Objekte

Es wird nur in Klassen gekabselt. In Objekten wird nichts gekapselt, also nicht direkt. Objekte gibt es nur zur Programmlaufzeit, weshalb ich hier die Begrifflichkeit in "Klassen" ändern würde. Man beschreibt doch eigentlich mit der Datenkapselung das Zusammenspiel von einzelnen Klassen untereinander?! Oder ist hier mit "Objekten", der Begriff eines realen Gegenstandes gemeint? Meinungen dazu ? e86 11:22, 27. Mai 2006 (CEST)

Objekte statt Klassen. Ich habe gerade den Artikel gelesen und bin unweigerlich über die IMO falsche Verwendung des Begriffs Klasse gestoßen. Klassen greifen nicht auf Klassen zu, sondern Objekte auf andere Objekte. Klassen beschreiben die Struktur von Objekten, zur Laufzeit -- alzu zum Zeitpunkt von Methodenaufrufen -- existieren Objekte. --85.178.27.118 01:52, 4. Jan. 2009 (CET)

Die meisten Daten existieren auch nur zur Laufzeit in Objekten, zumindest meistens, und sie gehören auch zu nur einem Objekt, in dem Sie gekapselt sein können. (nicht signierter Beitrag von 141.3.12.171 (Diskussion) 16:30, 17. Nov. 2008 (CET))

UML: Standardwert

Gibt es bzgl. der Sichtbarkeit einen Standardwert? D.h. wenn keine Sichtbarkeit spezifiziert ist, welche wird dann angenommen? Wäre als ergänzende Information im Artikel nützlich --Agent00 05:25, 14. Jan. 2008 (CET)

Package in C++

AFAIK gibt es in C++ keine Pakete. Friend bedeutet doch, "Die Klasse ist mein Freund, d.h. darf auf meine privaten Daten zugreifen", also etwas grundlegend anderes als z.B. internal. Ich hab's mal rausgenommen, weiß aber nicht ob das bei VB vielleicht auch falsch ist. --Grossergott 13:29, 14. Aug. 2008 (CEST)

Nachteile

Die aufgezählten Nachteile passen nicht zum Rest des Artikels. In "Datenkapselung im objektorientierten Paradigma" ist nur die Rede von Modifikatoren. Die Vorteile haben grösstenteils nichts mit Zugriffsfunktionen zu tun, die Nachteile ausschliesslich. (Der vorstehende, nicht signierte Beitrag stammt von 80.255.97.36) --Kgfleischmann 22:16, 16. Okt. 2008 (CEST)

Was auch nicht passt, sind sie Links in der Überschrift der Nachteile, nach meiner Erinnerung ist das unüblich!

--Kgfleischmann 22:11, 16. Okt. 2008 (CEST)

Vorteile

Der folgende Punkt gilt nicht nur für das Prinzip der Kapselung, da Zugriffsfunktionen auf Daten immer auch aus anderen Quellen stammen können: "Beim Zugriff über eine Zugriffsfunktion spielt es von außen keine Rolle, ob diese Funktion 1:1 im Inneren der Klasse existiert, das Ergebnis einer Berechnung ist, oder möglicherweise aus anderen Quellen (z. B. einer Datei oder Datenbank) stammt." (nicht signierter Beitrag von 94.217.102.249 (Diskussion) 14:13, 24. Jan. 2009 (CET))

Falsch

Inhaltlich ist der Artikel falsch. Datenkapselung (encapsulation) und Geheimnisprinzip (information hiding) sind zwei Paar Schuhe!
Datenkapselung sagt aus, dass zusammengehörige Attribute und Operationen in der Klasse verkapselt sind und Zugriffe auf Objektdaten nur über Methoden möglich sind, die mit den jeweiligen Objektdaten verknüpft sind. Es soll mit der Datenkapselung Datenkorruption verhindert werden, indem nur bestimmte Methoden einer Klasse Daten verändern können.
Das Geheimnisprinzip sagt aus, dass Attribute eines Objektes und die Realisierung einer Operation außerhalb der Klasse nicht sichtbar sind. Da diese Prinzip im gegensatz zur Vererbung steht ist es z.B. in C++ und Java nicht aufrecht gehalten. Es macht daher eher nur Sinn eine konsequente Verkapselung durchzuführen. -- Bkmzde 21:00, 30. Jun. 2009 (CEST)

Hmm, ja, die Gleichsetzung der Begriffe ist nicht korrekt. Datenkapselung ist eine besonders rigide Form des Geheimnisprinzips, aber das Geheimnisprinzip gibt es auch ohne Datenkapselung (Namespaces in heutigem Sprachgebrauch, in älteren Programmiersprachen oft als "Modul" bezeichnet).
Der Artikel sollte aufgesplittet werden. Wenn es keinen Widerspruch gibt, werde ich mich da mal drüber hermachen.
--Joachim Durchholz 15:26, 4. Sep. 2009 (CEST)

Ich würde Datenkapselung nicht einmal als irgendeine Form des information hiding sehen, auch wenn es dazu genutzt werden kann. Auch das bereitstellen von Daten, die sonst gar nicht zugänglich wären, gehört meines Erachtens dazu. Das ist wohl das Gegenteil vom Verstecken von Daten, als Ergebnis entsteht aber trotzdem eine Kapselung. Ein Leser des Codes sieht z.B. Getter und Setter, aus denen er folgern kann, dass etwas gekapselt wird. Ob der Entwicklers Verstecken oder erst zur Verfügung stellen will ist davon unabhängig. -- Kapep 12:27, 4. Aug. 2011 (CEST)

const ist auch eine art kapselung

• Die deklaration einer memberfunktion als const (und im grunde auch eines funktionsparameters) ist auch eine art von kapselung. Mir ist allerdings nicht bekannt, ob das auch in der literatur so gesehen wird und ich halte mich zurück, dass in den artikel einzufügen. Wer weiß das?
• Anm.: Die behauptung, dass es einen performancenachteil von zugriffsfunktionen gäbe, ist imo nicht haltbar, da der compiler/linker/optimierer das wieder ausgleicht.

--Oran 23:54, 8. Jul. 2009 (CEST)

• const dient wie die Kapselung dem Ziel, Module voneinander unabhängiger zu machen. Es ist aber ein ganz anderer Mechanismus: Kapselung verbirgt die Existenz einer Hintergrundmaschinerie, const verbirgt nichts, sondern sichert lediglich zu, dass keine Veränderungen an einem Datenobjekt stattfinden.
• Der Performancenachteil lässt sich zwar theoretisch wegoptimieren, in der Praxis funktioniert das aber oft nicht, weil der Compiler nicht weiß, welche konkrete Funktion aufgerufen wird (könnte ja die Funktion einer Unterklasse sein), oder weil eines von tausend anderen Optimierungshindernissen besteht.
  Faustregeln: Ordentliche Compiler können 90% der Fälle optimieren, richtig gute Compiler schaffen 95% oder 99%, ein Rest bleibt immer; manchmal sind Compiler unerwartet dämlich und optimieren nur 10% der Fälle; die Statistik über die Anzahl der optimierten Fälle sagt nichts darüber aus, wie oft sie im konkreten Programm aufgerufen werden.

--Joachim Durchholz 15:19, 4. Sep. 2009 (CEST)

Schon der erste Satz ist nicht korrekt

Als Datenkapselung bezeichnet man das Verbergen von Daten vor dem Zugriff von außen.

Gekapselte Daten müssen nicht unbedingt verborgen sein. Sie können auch öffentlich sein.

Wer behauptet nur privat Attribute wären gekapselt, public Attribute hingegen nicht? Das war eine rhetorische Frage.

Im englischen Artikel steht "bundling", was das Wesen der Datenkapselung meiner Meinung nach viel besser beschreibt.

Datenkapselung kann zum einen durch Klassen (private und öffentliche Attribute) aber auch durch Packages oder sogar durch Namespaces umgesetzt werden. Hier werden die Daten nur durch einen Bezeichner (den Namen des Namespace) gekapselt nicht aber durch Zugriffsmodifizierer.

Der Verbergen der Daten ist nur eine zusätzliches Merkmal der Datenkapselung, es ist nicht ihr Kern. (nicht signierter Beitrag von 2.206.136.246 (Diskussion) 12:07, 10. Mai 2022 (CEST))

Ich vermute, darauf gibt es unterschiedliche Sichten:

• deine Sicht, dass information hiding "nur eine zusätzliches Merkmal der Datenkapselung" ist und auch mit Namespaces etc umgesetzt werden könnte (ich vermute, da bist du ziemlich alleine dieser Ansicht)
• die Sicht, dass es zwei unterschiedliche, aber oft gemeinsam verwendete Konzepte sind - siehe z.B. https://www.infoworld.com/article/2075271/encapsulation-is-not-information-hiding.html bzw. der erste Satz in en:Encapsulation_(computer_programming)
• die Sicht, dass es zwei Sichten auf dasselbe Konzept ist - siehe z.B. zweiter Satz in en:Encapsulation_(computer_programming)

Unter en:Encapsulation_(computer_programming)#Meaning werden diese 2 Sichtweisen genauer beschrieben. Und ja auch wir sollten das hier aufnehmen, aber mMn nicht einen eigenen Artikel für information hiding machen.--Sebastian.Dietrich  ✉  08:24, 11. Mai 2022 (CEST)