Hallo zusammen, 
 

ich habe enorme Defizite im Verständnis der OOP und lese zur Behebung dessen folgendes Buch:
https://www.amazon.de/Objektorientierte-Programmierung-umfassende-Prinzipien-Objektorientierung/dp/3836262479/ref=sr_1_3?__mk_de_DE=ÅMÅŽÕÑ&crid=1VNWTTZDH8NEX&dchild=1&keywords=objektorientierte+programmierung+das+umfassende+handbuch&qid=1616942678&sprefix=objektorientierte+programmierung+%2Caps%2C156&sr=8-3

Nun bin ich in Kapitel 3 (Prinzip: DRY) auf folgende Passage gestoßen, die ich mir zum besseren Verständnis versucht habe zu verbildlichen. Aber irgendwie macht das für mich keinen Sinn, und ich bekomme einfach nicht herausgelesen, was man in der Passage eigentlich vermitteln möchte. Kann mir das jemand in verständlichen Worten, einem Bild oder einem super einfachen Praxisbsp. erklären?

Zitat

Noch interessanter wird es allerdings, wenn Sie beschließen, bestimmte Daten mit einer anderen Anwendung auszutauschen. Sie definieren eine Datenstruktur, die eine Anwendung lesen und die andere Anwendung beschreiben kann. Diese Datenstruktur muss in beiden Anwendungen gleich sein. Ändert sich die Struktur in einer der Anwendungen, muss sie auch in der anderen geändert werden.

Wenn Sie diese Datenstruktur in beiden Anwendungen separat definieren, bekommen Sie eine implizite Abhängigkeit. Wenn Sie die Struktur in nur einer Anwendung ändern, sind weiterhin beide Anwendungen lauffähig. Jede für sich allein bleibt funktionsfähig. Doch ihre Zusammenarbeit wird gestört. Sie werden inkompatibel, ohne dass Sie das bei der separaten Betrachtung der Anwendungen feststellen können.

Sofern möglich, sollten Sie also die Datenstruktur in einem neuen, mehrfach verwendbaren Modul definieren. Auf diese Weise werden die beiden Anwendungen explizit von dem neuen Modul abhängig. Wenn Sie jetzt die Datenstruktur wegen der nötigen Änderungen einer Anwendung derart ändern, dass die andere Anwendung mit ihr nicht mehr umgehen kann, wird die zweite Anwendung allein betrachtet nicht mehr funktionieren. Sie werden den Fehler also viel früher feststellen und beheben können.

Hier ein Zeichnungsversuch, an welchem ihr vermutlich schnell sehen werdet, dass ich nichts verstanden habe... (bitte achtet nicht auf UML-Konformität, dies diente nur der Illustration zum reinen Verständnis!)

 

Danke für eure Hilfe,

Fin

Hier ein sehnlich gewünschtes Bild eines Praxisbsp. von einem Freund zum besseren Verständnis:

@Finux

Zitat

Hier ein sehnlich gewünschtes Bild eines Praxisbsp. von einem Freund zum besseren Verständnis:

heißt das du hast es jetzt verstanden?

Falls nicht, schau dir nochmal das Prinzip der Modularisierung an. OOP versucht ja die Daten bestmöglich zu kapseln. Damit werden Sie auch wiederverwendbar und du brauchst dich nicht zu wiederholen und die Abhängigkeiten minimieren sich, bzw. spielen bestenfalls keine Rolle mehr.

Der zitierte Text ist meiner Meinung nach auch suboptimal

vor 10 Stunden schrieb r4phi:

Der zitierte Text ist meiner Meinung nach auch suboptimal

Zumal dies kaum was mit DRY zu tun hat, sondern eine Schnittstelle zwischen zwei Modulen/Anwendungen darstellt. Dabei muss es sich nicht mal um eine konkrete Klasse handeln, sondern kann auch einfach ein Interface sein und beide Module/Anwendungen implementieren für sich selbst das Interface.

vor 11 Stunden schrieb LouisCy:

OOP versucht ja die Daten bestmöglich zu kapseln.

Nicht wirklich. Datenkapselung funktioniert auch mit strukturierten Sprachen, wie z.B. in C. Es ist sogar so, dass die Datenkapselung in C++ kaputtging, da es nötig ist, private Member in der Headerdatei zu definieren. Der Benutzer der Klasse darf sie zwar nicht verwenden aber er bekommt über die Headerdatei die Information, dass sie existieren.

Es hat bei mir auch lange gedauert, bis ich die wahre Stärke von OOP wirklich begriffen habe und die liegt bei der Umkehrung der Abhängigkeiten. Ich kann Schnittstellen definieren und unterschiedliche Implementierungen besitzen. Ich kann also eine Schnittstelle für ein Logger definieren und entwickle zwei. Der eine schreibt die Log-Einträge auf dem Bildschirm und der andere in eine Datei und wenn eine andere Klasse einen Logger benötigt, kann ich entscheiden, welchen sie bekommen soll und dies sogar zur Laufzeit. Genau das und eigentlich auch nur das ist mit OOP möglich und nicht in strukturierten Programmiersprachen.

Bearbeitet 29. März 20214 j von Whiz-zarD

Ich bin mir nicht sicher, wie dein Lernstand in Bezug auf OOP aussieht. Wenn du allerdings Anfänger bist, dann würde ich dir dringend zu einem anderen Buch zu Beginn raten. JAVA lernen mit Blue J würde erstmal für Grundlagen sorgen, die kannst du anschließend mit dem Handbuch ausbauen.

vor 7 Stunden schrieb Whiz-zarD:

[...]Genau das und eigentlich auch nur das ist mit OOP möglich und nicht in strukturierten Programmiersprachen.

Findest du?

Ich kann mir gerade nur schwer vorstellen sowas wie Vererbung oder ADT umzusetzen.

Kannst du nochmal erläutern inwiefern die Datenkapselung kaputtgeht, wenn sie in der .h definiert wird oder meinst du das Geheimnisprinzip?

vor 2 Minuten schrieb LouisCy:

Ich kann mir gerade nur schwer vorstellen sowas wie Vererbung oder ADT umzusetzen.

Eine quasi Vererbung ist z.B. unter C möglich und wird auch verwendet. Es wird hier ein Trick verwendet, indem zwei Structs geschrieben werden, bei dem die Reihenfolge der Member, die beide enthalten sollen, gleich ist. Somit besitzen auch die Blöcke im Speicher die selbe Struktur und man kann mit einfacher Zeiger-Arithmetik die Member ermitteln. Somit kann man dann ein Struct in einen anderen Struct casten. Genau auf diese Weise ist die Vererbung in C++ gelöst worden.

Auch Polymorphie ist unter C möglich. Es gibt z.B. den Struct FILE, der in der stdio.h definiert ist. Dieses stellt quasi, mit Hilfe von Funktionszeigern, ein Interface dar. Jeder Treiber unter UNIX benutzt dieses Struct, um seine Funktionalität zu implementieren.

Klar, ist das alles nicht so komfortabel wie in objektorientierten Sprachen, da sie genau diese Überlegungen als Hauptkonzepte nehmen und syntaktischen Zucker drumherum bauen aber Vererbung und Polymorphie ist kein Alleinstellungsmerkmal der objektorientierten Sprachen.

vor einer Stunde schrieb LouisCy:

Kannst du nochmal erläutern inwiefern die Datenkapselung kaputtgeht, wenn sie in der .h definiert wird oder meinst du das Geheimnisprinzip?

Datenkapselung ist halt das Geheimnisprinzip. Es wird nur so viel preisgegeben, wie notwendig. Das klappt aber unter C++ nicht. Also verletzt C++ gegen das Geheimnisprinzip. Private Member müssen in C++ in der Headerdatei definiert werden. Die Headerdatei definiert aber die Schnittstelle nach Außen. Der Erzeuger dieser Klasse kennt ja die Headerdatei und somit auch die privaten Member, obwohl diese eigentlich niemanden von Außerhalb interessieren.