Unterschied objektorientiert-nicht objektorientiert??

[Yatzi]

Kann mir vielleicht jemand ganz kurz den Unterschied erklären? :confused:

[Crush]

Kurz ist gut ... =8-D

Objektorientierung:

Objekte sind logische Programmeinheiten. Diese bestehen aus Eigenschaften (Variablen und Inhalten) und Methoden (Programmaufrufe, Schnittstellen). Diese werden unter dem sog. Paradigma der „Kapselung“ welches auf dem Gedanken des Information Hiding basiert (versteckte Informationsinhalte) in Klassen verpackt. Klassen sind der Überbegriff über diese logischen Einheiten.

Sie haben „Schnittstellen“ oder „Methoden“, die nach außen hin für externe Programmzugriffe zur Verfügung stehen und zum Verändern oder Abfragen des Objekts da sind. Diese können von der Klasse selbst definiert und von übergeordneten Klassen geerbt werden.

Desweiteren gibt es Daten und Funktionen, die nach außen hin unsichtbar sind und nur intern innerhalb der Klasse, bzw. der Objekte verwendet werden können (Klassen-, Membervariablen und -methoden).

Es wird ähnlich wie bei Datenbanken alles Redundante weggelassen und kleinrationalisiert, mehrfache Datensätze werden durch Indizes bei Datenbanken auf ein Minimum an Speicheraufwand reduziert. Eine Klasse sorgt genauso dafür, daß alle einheitlichen Informationen und Programmcode von gleichartigen Objekten auch für alle Objekte sozusagen über den Klassenindex verwendet werden können.

Eine Klasse ist sowohl ein Schnittpunkt für alle Objekte, als auch eine Art „Schablone“ für neue Objekte die aus dieser Klasse gebildet werden können (Instanzieren). Allerdings kann eine Klasse auch Vorlage oder Inhalt einer anderen Klasse sein!

Diese Klasseneinteilung hat die Vorteile, daß Klassen bequem in neue Programme integriert werden können, der Compiler schneller Programmcode erzeugen kann, weil es sich auch anbietet Klassen in eigene Dateien auszulagern. Daraus lassen sich vorkompilierte Programmobjekte erzeugen (nicht mit den OO-Objekten verwechseln), die der Linker sehr schnell zu einer Ausführbaren Datei zusammensetzen kann. Eine funktionsfähige Klasse kann einfach benutzt werden, weil die Schnittstellen nach außen ja schlicht, funktionell und unkompliziert gehalten sind – oder jedenfalls sein sollten.

Objekte kann man also aus unterschiedlichen Sichtweisen betrachten, was auch etwas mehr Verständnis für diese Programmiertechnik bringt:

Aus Sicht der Klasse:

Es gibt Eigenschaften und Methoden, die für das einzelne Objekt definiert sind, aber auch welche, die für alle Objekte gleichzeitig gelten und verwendet werden (Klassenvariablen und Klassenmethoden). Die Klasse ist der Überbgriff für die Objekte und legt fest, wie diese sich zu verhalten haben. Es ist möglich Objekthierarchien zu erstellen, Beziehungen zueinander zu definieren und so Objekte wie ein Baukastensystem zusammenzubasteln.

Aus Sicht des Objekts:

Ein Objekt betrachtet meist nur sich selbst und seine Dateninhalte. Diese werden von außen durch „Nachrichten“ (was aber nichts weiter als Methodenaufrufe sind) verändert. Es gibt Fälle, in denen die Objekte andere Objekte beeinflussen, aber das ist eher selten der Fall, weil dadurch die Gefahr besteht, daß unerlaubte Zugriffe zu unsicherem Code führen können.

Aus Sicht von externen Programmteilen:

Ein Objekt wird einfach benutzt. Es kann durch seine Methoden verwendet werden, bietet in C++ jedenfalls Möglichkeiten Kopien anzulegen oder eigene Operatoren zu definieren, mit denen man diese Objekte verwalten, verändern und vervielfältigen kann. Was wirklich innerhalb des Objekts passiert interessiert den Benutzer nicht. Wichtig ist nur, daß das Objekt seinen Zweck erfüllt.

Das sollte fürs Erste ausreichend sein.

Stellt sich jetzt nur die Frage, was ist „nicht objektorientiert“?

Früher wurden natürlich auch Objekte unter dem Deckmantel einer Struktur erstellt und verwendet. Diese Strukturen waren jedoch schlecht geschützt und es war Aufgabe des Programmierers die richtige Funktion auf die richtige Struktur anzuwenden. Dadurch waren Programme fehleranfälliger und die Fehlersuche konnte unheimlich kompliziert sein. Ehrlich gesagt kann auch heute noch die Suche nach Fehlern einem graue Haare wachsen lassen, aber das hat auch noch andere Gründe.

Hinsichtlich der wachsenden Komplexität der Programme und der schnelleren Softwareentwicklung unter dem Gesichtspunkt der Wiederverwendbarkeit von Programmcode wurde das Klassen- und Objektkonzept entwickelt. Dadurch war es einfacher möglich große Programmprojekte bequem zu realisieren. Auch das Austauschen von Programmcode ist einfacher, weil ja nur die Internas der Klassen geändert werden müssen, jedoch nicht die externen Schnittstellen. So ist es möglich eine maximale Kompatibilität zu bestehenden Programmen zu gewährleisten. Außerdem ist es dadurch möglich geworden Compiler mehr "Intelligenz" auf der Suche nach möglichen Fehlerquellen zu verleihen, weil dieser alle Bedingungen kennt, die für Klassen und Objekte gelten. Verstöße führen zu Compilerfehlern und auf diese Art und Weise wird nicht mehr nur roh die Syntax der Programmiersprache kontrolliert.

Die Objektorientierung wurde also als Mittel entwickelt dem Programmierer das Leben leichter zu machen und der steigenden Anforderungen an die Software und dem Ruf nach zuverlässigeren und wiederverwendbareren Programmen nachzukommen.

<FONT COLOR="#a62a2a" SIZE="1">[ 13. Dezember 2001 12:00: Beitrag 11 mal editiert, zuletzt von Crush ]</font>

[Hexagon]

Ich versuchs mal kürzer :

Objektorientiert:

Versuch einfach die Welt abstrakt darzustellen. D.h.:

Alles sind Objekte mit Eigenschaften(Attributen, Membervariablen) und Funktionen(Memberfunktionen).

Problemorientiert:

Kümmere dich nicht um Eigenschaften und Funktionen, sondern nur auf die Werte(Variablen) die du zur Problemlösung nötig sind und auf deren Verarbeitung!

Ich weis nicht besonderst gut, aber ein Versuchs wars wert!

[Crush]

Also Objekte soll man ja als Abbildung der Realität betrachten, was soll daran denn abstrakt sein? Vielleicht hast Du das mit den (rein) virtuellen Klassen verwechselt.

Beispiel: Geomfigur=abstrakte Klasse (sagen wir mit Attributen Längen- und Breitenausdehnung oder Durchmesser), abgeleitete Klassen, welche dann Objekte Bilden können wären Dreieck, Rechteck, Viereck und als Sonderfall vielleicht noch Kreis. Von denen kann ein Objekt existieren und damit machen sie Sinn.

Eine abstrakte Klasse soll Eigenschaften enthalten, die man auf eine sinnvolle verwendbare Einheit erweitern kann. Eine Geomfigur alleine ist unsinnig, weil sie ja definitiv keine "echte" Form hat.

Abstrakt ist höchstens für viele die objektorientierte Denkweise!

"Die Welt" möchte ich aber noch etwas verständlicher formuliert haben - oder meinst Du etwas ALLES?

Wer sagt eigentlich, daß objektorientiere Programme nicht problemorientiert sind? Das würde ja bedeuten OO schießt am Ziel vorbei, oder wie soll man das auslegen?

<FONT COLOR="#a62a2a" SIZE="1">[ 13. Dezember 2001 21:22: Beitrag 2 mal editiert, zuletzt von Crush ]</font>

[Hexagon]

Na Hallo!

Abstrakt bedeutet nur: Reduziere auf das Nötigste und Verwendbareste! Oder ansderst:

Ich hätte gern von dir eine Klasse Mensch mit allen Eigenschaften und Funktionen! :eek:

Und natürlich ist OOP auch problemorientiert, aber du gehst davon aus, das alles mit den Eigenschaften/Funktionen der Objekte lösbar ist!

Ist das verständlicher??? :confused:

[Crush]

Schon verständlicher, aber die Objektsicht bedeutet ja nicht, daß die Objekte sich selbst verwalten .. sie werden schließlich benutzt - da gehe ich nur halt nicht weiter drauf ein, die externen Programme übernehmen die grobe Verwaltung der Objekte - und hier ist ja auch das eigentliche problemorientierte Programm enthalten.

Man kann das OO-System auch als eine höher organisierte Programmstruktur betrachten, das liegt dem wohl näher. Im Endeffekt wird bei beiden Programmierstilen immer noch gleich gearbeitet.

Die gleichen Funktionen sind hier und da, die gleichen Daten und die gleichen Routinen führen zum gleichen Ergebnis. Nur, daß die Objekt- & Klassenstruktur eine einfachere Wiederverwendbarkeit ermöglicht - und Compilefehler leichter geortet werden können.

Ich finde man sollte nicht so machen als ob OO das Nonplusultra ist und eine völlig andersartige Methode zu programmieren. Sie ist lediglich ein sinnvoller Folgeschritt der Programmiersprachenentwicklung. Andere werden mit Sicherheit noch folgen!

[DocMabuse]

Hi!

Hexagon spielt vermutlich auf die 4 Paradigmen der OOP an (Datenabstraktion, Datenkapselung, Vererbung und Polymorphie). Ich habe jetzt nicht wirklich Zeit und Lust, die Begriffe komplett zu erklären, aber ich habe hier einen Link auf ein PDF-Dokument, in dem alles erklärt wird. Es lohnt sich, da mal reinzuschauen.

Grüsse!

DocMabuse

[gajUli]

<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica, sans-serif">Zitat:</font><HR>Original erstellt von DocMabuse:

<STRONG>Hi!

Hexagon spielt vermutlich auf die 4 Paradigmen der OOP an (Datenabstraktion, Datenkapselung, Vererbung und Polymorphie). </STRONG>

[Hexagon]

<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica, sans-serif">Zitat:</font><HR>Original erstellt von ElektroUli:

<STRONG>

Dann hiesse es wohl Tetragon.

Uli</STRONG>