Verstehe die Objektorientierung nicht...

Hallo,


Lerne momentan Java und bin jetzt bei der Objektorientierung die ich überhaupt nicht verstehe. Ich verstehe außerdem den Sinn und Zweck der Objektorientierung nicht.

Datentypen,Anweisungen und Operatoren habe ich mittlerweile ganz gut verstanden und weiß auch wofür man sie einsetzen könnte z.B. die if-Anweisung oder die switch-Anweisung .. nur bei der Objektorientierung fehlt mir das Verständis, hatte mir schon sehr viele Beiträge dazu angeschaut, aber habe es trotzdem nicht verstanden. Wie könnte ich es also am besten lernen? Ich brauche dafür ein sehr verständliches und gutes Beispiel, dass jeder verstehen könnte. Ich weiß nur, dass eine "Klasse" in Java ein Bauplan zu einem Objekt darstellen soll. Und dass Objekte Attribute, Eigenschaften, und Parametern besitzen können. Verstehe es halt trotzdem nicht :/ z.B. gibt es da noch Instanzvariablen und Konstruktoren... Also alles was mit der Objektorientierung zu tun hat. Ich lerne es momentan auf Codecademy und habe langsam meine Zweifel, ob die das überhaupt richtig erklärt haben. Also die Objektorientierung. ...

Könnt ihr mir eine Seite vorschlagen, wo man es ganz genau erklärt bekommt? Für Java natürlich.
Oder kann es mir jemand erklären?






MFG

"java ist auch eine Insel" ist ein hervorragendes Einstiegswerk für Java und Objektorientierung.
Es fängt bei den Basics an und steigert sich recht machbar in nicht zu großen Schritten.
Wie weit du dann reingehst, bleibt dir überlassen.

Objektorientierung zu verstehen ist wirklich kein Hexenwerk, sondern eigentlich total intuitiv und logisch, da eben von der Realtität abgeleitet

Um mal zu versuchen es ganz einfach zu veranschaulichen:

Du hast die Klasse "PC", die hat übersichtshalber jetzt nur eine Bezeichnung und das CPU Modell als Attribut.

Im Programm kannst du jetzt Objekte dieser Klasse anlegen

PC computer1 = new PC("Wohzimmer-PC", "i5");
PC computer2 = new PC("Kinder-PC","i3");

Jetzt hast du 2 Objekte der Klasse PC, computer1 und computer2. Das wars eigentlich, du hast verschiedene Instanzen der gleichen Klasse, die unabhängig sind, das ist OOP

Instanzvariablen sind hier einfach die Bezeichnung und das CPU-Modell, da es jeder Instanz eigens zugeordnet wird.
Der Konstruktor ist der Code in der Klasse, der bei der Erstellung einer Instanz (siehe oben) die Attribute festlegt, das macht er mit den übergebenen Parametern.

Ein Objekt ist die Instanz einer Klasse oder auch eines Datentyps. Die Instanz wird durch Konstruktoren erstellt, die selber nur Routinen darstellen was geschehen soll, wenn eine Bezeichner als neues Objekt definiert wird. In diesen Konstruktoren werden meist nur die Standardwerte der Eigenschaften einer Klasse festgelegt.

Klassen sollen etwas Klassifizieren. Das Beispiel von coolmodi zeigt dies.

In einer nicht objektorienterten Programmiersprache (mit Datentypen) kann ein Bezeichner alles sein. Zum Beispiel kann der Bezeichner "a" ein Integerwert (z.B. a=1) sein, und der Bezeichner "b" ein String (z.B. b="Hallo"). Eine Zuweisung der Art c=a+b würde demnach ergeben: 1+"Hallo". Das macht (meistens) keinen Sinn, wäre aber möglich (Stichwort wäre hier: Homoikonizität). Eine objektorienterte Programmiersprache erlaubt soetwas nicht, solange der Operator "+" nicht genaue Anweisungen bekommt, wie eine solche Zuweisung zu behandeln wäre. Ein Vorteil der objektorientierten Sprachen ist also, dass eine saubere Trennung von nicht vereinbaren Zuweisungen garantiert ist. Dadurch geschehen deutlich weniger Fehler. Außerdem ist es intuitiver.

Man kann sich Objekte also so wie Physikalische Größen vorstellen. Alle Basisgrößen tragen unterschiedliche Einheiten. Z.B. kannst du eine Energie E in Joule nicht mit einer Spannung U in Volt verrechnen. Das ergebe keinen Sinn. E und U sind vor einer Instanzierung ersteinmal nur Bezeichner. Mit der Instanzierung werden es Objekte der Klassen "Energie" und "Spannung".

Ein anderes Beispiel wäre eine Rakete mit folgendem Szenario. Der Navigationscomputer könnte irgendwelche Flugdaten dem Steuerungscomputer der Triebwerke übermitteln. Zum Beispiel Daten der Art "Jetzt 1 Grad nach links". Fällt der Navigationscomputer aber aus, spuckt dieser nur noch Fehlernummern aus, die der Steuerungscomputer aber dummerweise als Flugdaten interpretiert. Der Steuerungscomputer kennt den Unterschied zwischen Fehlerdaten und Flugdaten nicht, wenn es keine Objektzuweisung gibt. Als Folge stürzt die Rakete ins Meer. Würde der Navigationscomputer aber stetig Objekte übergeben, wüsste der Steuerungscomputer sofort wie die Objekte zu interpretieren sind. "Flugdaten" und "Fehlerdaten" wären hier Klassen. Erhält der Steuerungscomputer Objekte die durch die Klasse "Flugdaten" instanziert worden sind, dann ist alles okay. Erhält er Objekte die der Klasse "Fehlerdaten" entstammen, dann macht er wenigstens keinen Blödsinn.

Ganz simpel kann man sagen, dass was früher strukturierte Datentypen waren sind heute (erweitert) Objekte. Sie sind eine logische Zusammenfassung von Parametern, Funktionen, etc.
Im Beispiel von coolmodi würde das z.B. bedeuten: 1 Objekt des Typ PC besteht aus zig Komponenten Hardware, man kann ihn ein/ausschalten usw.
PC -> Mainboard
PC -> CPU
PC -> Einschalten()
PC -> Ausschalten()
PC -> Aktueller Status
etc.

Allerdings ist das nur ganz grob vereinfacht, für einen ersten Überblick sollte es wohl reichen.

Objektorientierung mag in kleinen Programmen noch überflüssig sein, in einem riesigen Programm wirst du ohne komplett aufgeschmissen sein, wenn sich der Code quer über tausend Methoden verteilt, ohne sauber strukturiert zu sein. Daher ist es sinnvoll auch bei jeden kleinen Programm sauber zu arbeiten, auch wenn es teilweise mit erhöhtem Aufwand verbunden ist.

Wenn Du die Kapitel zur Objektorientierung nicht verstehst, dann suche ein anderes Buch. Das Thema Objektorientierung ist eigentlich sehr leicht verständlich, aber wie so oft im Leben nicht immer leicht einzusetzen.

Sieh es mal so, die Objektorientierung ist ein Werkzeug, um eine Anwendung zu erstellen und aktuell der Standard, wie man entwickeln sollte. Ich versuche es einmal etwas abstrakter zu formulieren und zum Ende den Bogen zur Objektorientierung zu spannen.

Es wäre hilfreich zu verstehen, dass man eine neu zu entwickelnde Anwendung vernünftig strukturieren muss, damit sie gut funktioniert und später auch einfach weiterentwickelt werden kann. Das ist wie ein Haus bauen oder eine Maschine konstruieren. Alles hat seinen Platz und seine Reihenfolge, in der man das macht.

Bei einer klassischen Businessanwendung strukturiert man seinen Code in Komponenten und Layer. Komponenten sind kleine Bausteine, die eine Aufgabe oder Arbeit für Dich erledigen. Layer bündeln eine oder mehrere Komponenten zu einer logischen Einheit.
In klassischen Businessanwendungen hat man typischerweise 3 Layer. Es können natürlich auch mehr sein. Aber bleiben wir beim einfachen Beispiel. Das wäre je ein Layer für die Benutzeroberfläche (GUI), die Geschäftslogik und die Datenzugriffsschicht (Datalayer).

Und jetzt kommen wir zur Objektorientierung.

Ein Anwendungsfall, eine Klasse zu definieren und zur Laufzeit der Anwendung eine oder mehrere Instanzen (=Objekte) der Klasse zu erzeugen ist ein Datenmodell. Ein Beispiel wäre eine Kundenkartei einer Firma. Jeder Kunde ist eine Person mit einem Namen, einer Anschrift für die zu erstellende Rechnung und eine Anschrift für die Lieferung der Ware, sowie einer Bestellung.

Schon hast Du einen Hinweis, auf die Klassen, die Du entwickeln musst. Das wären z.B.:

- Person
- Adresse
- Rechnung
- Bestellung

Jede Klasse hat dann bestimmte Eigenschaften. Z.B. hat die Person, die Eigenschaften (=Property oder Get-, und Set-Methode) oder Attribute (= Felder oder globale Klassenvariable) "Rechnungsadresse" und "Lieferadresse" vom Typ der Klasse "Adresse".

Also merke Datenmodelle werden als Klassen modelliert und sind der einfachste Anwendungsfall für die Objektorientierung.

Dann gibt es noch den Anwendungsfall, dass man mit Daten arbeiten möchte. Stell Dir vor, Du benötigst ein Werkzeug, um Deine Daten zu verarbeiten.

Das wären dann z.B. die Klassen der Geschäftslogik. Das sind Klassen, die keine oder kaum Daten in internen Feldern oder Eigenschaften speichern sondern fast nur Methoden enthalten. Diese Methoden nehmen Daten-Objekte entgegennehmen und machen damit irgendetwas.

Ein Beispiel. Du klickst in Deiner Geschäftsanwendung auf eine Kundenbestellung. Die Klasse der Benutzeroberfläche versteht diesen Mausklick und ruft eine Klasse der Geschäftslogik auf. Denke an die 3 Layer, die ich oben erwähnt habe!. Die Klasse der Geschäftslogik ruft eine Klasse des Datalayers auf, die die benötigten Daten aus der Datenbank holt. Dann macht die Geschäftslogik irgendetwas damit, z.B. könnte sie über eine andere Klasse des Datalayers prüfen, ob die Ware aus der Kundenbestellung auch im Lager vorrätig ist und das im Datenmodell der Bestellung mit speichern. Dann werden die Daten als Datenobjekt an die Benutzeroberfläche übergeben, wo eine weitere Klasse einen Ansicht für den Anwender daraus erzeugt.

Das ist nur ein grob skizziertes Beispiel. Die Objektorientierung hilft Dir bei der Bewältigung all dieser Aufgaben. Richtig verstehen wirst Du es aber erst, wenn Du Dich an so einem Beispiel versuchst. Du bist mit dem Lernen auch nicht nach einem Jahr fertig, auch wenn Du bis dahin sicher viel gelernt hast. Mit jedem neuen Projekt, wirst Du ein tieferes Verständnis erlangen.

Schreib vor allem viel Code. Experimentiere damit ausgiiebig rum und so.
Wenn Du nur Anleitungen abarbeitest und vielleicht hier und da mal ein Beispiel abtippst und ausführst, wird sich der Lernerfolg in Grenzen halten.
Programmieren hat auch ganz viel mit Learning by doing zu tun.

Dann wird sich bei vielen Sachen der Aha-Effekt von ganz allein einstellen.

can320 schrieb:

Objektorientierung mag in kleinen Programmen noch überflüssig sein, in einem riesigen Programm wirst du ohne komplett aufgeschmissen sein, wenn sich der Code quer über tausend Methoden verteilt, ohne sauber strukturiert zu sein. Daher ist es sinnvoll auch bei jeden kleinen Programm sauber zu arbeiten, auch wenn es teilweise mit erhöhtem Aufwand verbunden ist.

Zum Vergrößern anklicken....

Die Abwesenheit von OOP impliziert nicht das Fehlen eines Konzepts bzw. eines klar strukturierten Programms. OOP hat durchaus seine Daseinsberechtigung, aber diese Wahnvorstellung, dass OOP der einzige Weg ist, muß langsam mal sterben.

Das stimmt.

"Keep it simple" und "Don't repeat yourself" sind die obersten Paradigmen.

Probier'n bisschen rum und google... Du hast einen ziemlich hohen Verschleiß an Threads.

https://de.wikipedia.org/wiki/Objektorientierte_Programmierung

Das Beispiel mit den Autos könnte es vielleicht schon verdeutlichen, ansonsten google nach "java insel".

Verstehst Du jetzt ein bisschen mehr?