Was bedeutet Objektorientiert??

M

mac_in_tosh

Aktives Mitglied
Thread Starter
Dabei seit
20.05.2007
Beiträge
217
Reaktionspunkte
0
Hallo zusammen,
ich bin am überlegen, ob ich Cocoa lernen soll, deshalb habe ich mich mal in Foren und auf Webseiten ein bisschen umgeschaut. Überall wird dort von Objektorientiert gesprochen. Aber ich weiss nicht, was das bedeutet. Kann mir mal jemand erklären, was es mit diesen Klassen, Objekten etc auf sich hat??
vielen Dank schon im Voraus!
 
objektorientierung ist ein paradigma.
da wird halt grob gesagt die reale welt in objekten nachgebildet...

jedes halbwegs gute lehrbuch dazu, erklärt dir das auch ausführlich ;)

aus deinen andern programmier problemen würde ich jetzt mal schliessen, dass dir ja mal jede grundlegende literatur zu gemüte führen solltest ;)
 
Du meinst sicher, was objekt-orientierte Programmierung bedeutet.

Vereinfacht kann man sagen, dass OOP die Kapselung von Daten und Methoden zu einem Objekt beschreibt. Dies bedeutet, dass du bei der wie auch immer gearteten Herstellung eines Objektes beides erhältst. Gleichzeitig führt dies dazu, dass das Objekt seine Daten kennt und daher auf seinen Daten arbeitet.

Mal als Beispiel:

// Nicht-OOP
handle = fileopen( … );
data = fileread( handle );
fileclose( handle );

// OOP
fileobject = file( … );
data = fileobject.read();
fileobject.close();

Wie du sehen kannst, wissen die OOP-Methoden um welche Datei es sich handelt, während die Nicht-OOP Funktionen diese Daten mitgeteilt werden müssen. Es liegt also eine Trennung von Daten und Methoden vor.

Der Begriff stamm allerdings von Alan Kay und er hat ihn vor allem so verstanden, dass OOP zwei Dinge ausmachen:

a) Objekte wie oben
b) Nachrichten, die Objekte austauschen.

Dies bedeutet, dass eigentlich nicht eine Methode "aufgerufen" wird, sondern ein Objekt eine Nachricht erhält, die dann in einem zweiten Schritt auf eine Methode assoziiert wird -- und zwar vom Empfänger. Im heutigen Sinne wird OOP allerdings nur mit a) verstanden.

Darüber hinaus sind je nach Programmiersprache weitere Technologien zentral, die durch OOP erst möglich oder sinnvoll werden, etwa Vererbung.
 
  • Gefällt mir
Reaktionen: mac_in_tosh
Neben der Kapselung von Daten und Zugriffsmethoden auf die Daten in einer Blackbox (Objekt), ist es auch wichtig zu verstehen das daraus ein anderer Denkansatz und somit ein anderer Entwurf von Software entsteht!

Bei OO "weiß" ein Objekt wie es sich verhält. Ein Objekt Auto kann z.B.: fahren, bremsen, tanken, beladen, parken, lenken, diagnose durchführen,...

Auch ein Traktor ist im weitesten Sinne ein Auto. Er wird ein paar Funktionen mehr haben (Hydraulik,...), zahlreiche Gänge mehr, aber man kann ihn auch fahren, bremsen, tanken, beladen, parken, lenken,...

somit kann man ein Fahrzeug

fzg1 = auto
fzg2 = trecker

erstellen und beide mit den Methoden

fzg1.fahren und fzg2.fahren in Bewegung setzen ( rein virtuell). Daraus ergibt sich eine ganz andere "Denke" als bei Ablauf/Befehlsorientierten Programmieren

"Schliess die Tür auf"
"Setz Dich auf den FAhrersitz ( vo. li oder re. je nach Herkunft des KFZ)"
"Steck den Schlüssel ins Zündschloß"
"Stell sicher das kein Gang eingelegt ist"
....


Diese imperative Ablaufbeschreibung muß ganz anders geplant werden, wiederkehrende Abläufe werden in Funktionen abgelegt. Fahrzeuge die ganz andere Abläufe aufweisen ( etwa KFZ mit Starter, Automatik KFZ,...) bekommen individuelle Abläufe. Häufig erfindet man das Rad neu, greift kunterbunt von einer Abhängigkeit auf Daten einer anderen Abhängigkeit zu...

imperative oder funktionale Programmierung ist nichts Schlechtes und OO nicht immer die Lösung schlecht hin. Mit OO lassen sich aber komplexere Abläufe besser modellieren und Code-Fragmente hängen nicht so sehr von anderen Fragmenten ab. Bei Objekten kann man einen Objekttyp leicht durch einen anderen ersetzen - Hauptsache er erfordert den Mindestkatalog an Methoden ( das nennt etwa ein man Interface).

Grundsätzlich ist es wichtig zu wissen das mit der Kapselung von Daten und Methoden in einem Objekt und dem Ansatz "Alles ist ein Objekt" eine ganz andere Entwurfsdenke braucht. Nur vom Vorsatz "ich verwende Objekte" ändert man nichts; man muß auch damit arbeiten/denken können. Im Grunde schematisieren und entkoppeln Objekte die Schnittstellen die zur Kommunikation untereinander nötig sind. Man erhält quasi einen Modulbaukasten in dem jedes Objekt ähnlichen/gleichen Ausgangstypes ein anderes ersetzen kann. Bei imperativer Programmierung ist das nicht immer sichergestellt. Mag sein, daß das Wissen zum reparieren eines KFZs nicht zum Auto gehört und daher beim Mechaniker "einprogrammiert" ist. Was ist aber mit dem Reifenwechsel? Den muß auch der Fahrer können. Gehört Reifenwechseln somit zum Auto? Der eine macht das vielleicht so, der nächste erklärt sein Fahrer sei ein "Mechaniker light" . Die Zuweisung von Rollen, Methoden,Abhängigkeiten und die Festlegung der Kommunikation dadurch schliessen so ein wirrwarr bei OO weitgehend aus, einfach weil es zuallererst festgelegt werden muß. Bei imperativer Programmierung kann es passieren das der Trecker-Programmierer das Reifenwechseln beim Fahrer sucht. Der Maybach-Programmierer wird es als Service-Option in das GSM-Modul seines KFZ integriert haben. Im Notfall könnte also der Maybachfahrer nicht Trecker fahren was ja unerwünscht wäre ( auch wenn es der Realität hier näher käme)

Einige der gängigen Verhaltensweisen im Umgang mit Objekten und vor allem ihrer Interaktion stehen z.B. in diesem Buch:

[ISBN]0596007124[/ISBN]

leider bezieht es sich auf Java, auch wenn man die Beispiele auch in anderen OO-Sprachen nachvollziehen kann. Ob es so etwas für Objective-C auch gibt weiß ich nicht. Viele der dort beschriebenen Verfahren gelten sicher auch für Objective-C. Einiges wird dort aber sicher eleganter handhabbar sein, da der Ansatz von Objective-C ein leicht anderer ist. Objective-C brauchst Du wenn Du mit Cocoa arbeiten möchtest.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: mac_in_tosh
anegmawad schrieb:
Es gibt so eine Art "Design-Patterns in Cocoa"-Fibel, die auch Links zu weiteren Artikeln enthält.
http://developer.apple.com/document...3.html#//apple_ref/doc/uid/TP40002974-CH6-SW5
Zum Vergrößern anklicken....

Sehr schöner Artikel. Als Begleitlektüre eignet sich besonders die Gang of Four, auf die in dem Apple Artikle implizit bezug genommen wird.
ShowCover.aspx


Alex
 
genau für die Design-Patterns der Gang of 4 ist der link von mir ein praxisbezogenes Buch. Die "wichtigsten" Design Patterns werden dort anhand von Beispielen vorgestellt (warum und wie macht man das). IMHO ein ganz wichtiger Punkt um OO entwerfen zu können.
 
Wobei man GoF auch erst lesen sollte, wenn man in OOP drin steckt. OOP geht auch ohne, GoF ist ja schon die hohe Kunst von OOP =)
 
  • Gefällt mir
Reaktionen: below
Wirklich schön erklärt wegus. ;)

So habe gerade mal in meiner Safari Library geschaut:
Objektorientierung bezogen auf Objective-C wird im Buch "Learning Cocoa with Objective-C" von James Duncan Davidson und Apple Computer recht ausführlich erklärt.

Auch im Buch "Programming in Objective-C" von Stefan G. Kochan gibts dazu ein schönes Kapitel.

Das wohlbekannte Buch von Hillegass habe ich jetzt mal nicht aufgezählt, da OO dort doch recht knapp ausgefallen ist und sich somit doch etwas mehr an Leute mit Vorkenntnissen in diesem Bereich richtet.
 
Vielen Dank!!Also wenn ich das richtig verstanden habe, dann ist der Unterschied, dass in der Objektorientierten Programmierung jedes Objekt genau weiss, was es kann. In der nichtobjektorientierten Programmierung, muss man einem Objekt den genauen Ablauf erklären.
 
mac_in_tosh schrieb:
Vielen Dank!!Also wenn ich das richtig verstanden habe, dann ist der Unterschied, dass in der Objektorientierten Programmierung jedes Objekt genau weiss, was es kann. In der nichtobjektorientierten Programmierung, muss man einem Objekt den genauen Ablauf erklären.
Zum Vergrößern anklicken....
Äh, nein. In der nicht-OOP muss man einem Objekt gar nichts erklären. Sonst wäre es ja OOP. ;-)

Also, der Unterschied besteht weniger im Ablauf eines Stückes Code. Das, also sozusagen das Atomare, funktioniert bei beiden gleich. Der Unterschied besteht darin, dass das Stück Code bereits "seine" Daten kennt. Dadurch sind Daten und Ablauf "verheiratet".

http://cocoading.de/Sonstiges/OOP.jpg

Im ersten Beispiel hast du ein Stück Code und der Aufrufer liefert dreimal verschiedene Daten, nämlich die Pfad der zu lesenden Dateien.

Im unteren Teil bilden der Pfad und die Funktionalität eine Einheit. Das heiß, der Aufrufer liefert gar nichts und du hast "virtuell" drei Objekte mit jeweils einem (gleichen) Stück Code und einem Pfad.

Weist du unten also etwa das Datei-Objekt einer anderen Variable zu, so weist du "logisch" gleich den Code für die Leseoperation mit zu.

+++

Jetzt stell dir noch vor, die Pfade sind jeweils Bilddateien und genau diese sollen gelesen werden. Im ersten Fall musst du dir irgendwie merken, welche Art von Bild (JPG, IMG, TIFF usw.) du hast. Dann musst du jedes Mal entscheiden, welches Stück code lese_jpg, lese_tiff usw. ausgeführt werden soll. Wird das einer anderen Variablen zugewiesen, musst du bei der Benutzung dieser Variablen wieder entscheiden usw.

Im OOP-Ansatz wird einfach bei der Erzeugung des Objektes einmal überprüft, was dsa richtige Objekt für die konkrete Datei ist. Demnach wird einmal ein Tiff-Ojekt, einmal ein JPG-Objekt usw. erzeugt. Später bekommt jedes Objekt die immer gleiche Nachricht "lese". Dieses Objekt, die Verheiratung der Datei mit dem Code, hat ja stets den "richtigen" code für den richtigen Typen. Das kannst du jetzt auch zuweisen wie du willst.
 
Zuletzt bearbeitet:
was dagegen ? schrieb:
Wobei man GoF auch erst lesen sollte, wenn man in OOP drin steckt. OOP geht auch ohne, GoF ist ja schon die hohe Kunst von OOP =)
Zum Vergrößern anklicken....
In der Tat geht wegus' Beitrag sehr in die Richtung, was man mit OOP machen kann. Gedanklich kann man das von der Frage trennen, was OOP ist.

Allerdings ist das technologisch so sehr gegenseitig bezogen, dass dsa eine ohne das andere irgendwie wenig sinnvoll ist.
 
anegmawad schrieb:
In der Tat geht wegus' Beitrag sehr in die Richtung, was man mit OOP machen kann. Gedanklich kann man das von der Frage trennen, was OOP ist.

Allerdings ist das technologisch so sehr gegenseitig bezogen, dass dsa eine ohne das andere irgendwie wenig sinnvoll ist.
Zum Vergrößern anklicken....

Ja das hast Du sehr treffend geschrieben. Mag sein, dass das auch daher rührt das ich noch aus der imperativ/funktionalen Zeit komme. Ich hab auch erst gedacht "na dann nimmste halt diese praktischen STRUCT die ihre Methoden gleich mitbringen" und machst in OO". Bis ich gelernt hab das das gar nicht reicht/wenig bringt. Dann gelernte Mechanismen wieder gezielt abzulegen und umzudenken war ( und manchmal ist es das auch noch) ein hartes Stück Arbeit.

Von daher gehören Entwurf ( und somit Design Patterns) und Technologie für mich dabei zusammen.
 
anegmawad schrieb:
// Nicht-OOP
handle = fileopen( … );
data = fileread( handle );
fileclose( handle );

// OOP
fileobject = file( … );
data = fileobject.read();
fileobject.close();
Zum Vergrößern anklicken....
Hm. Also bei der Nicht-OOP gehen Pfad und Handlung quasi einen getrennten Weg, d.h. die Handlung ist fileclose und der Pfad ist ( handle ).
Bei der OOP hingegen sind Pfad und Handlung zu fileobfect.close(); vereint.
Ist das so richtig?
 
im Grunde ist das so ja!

Objekte enthalten neben den Variablen die sie benötigen auch alle Methoden mit denen man auf das Objekt zugreift. Hier etwa zum öffnen, schliessen, lesen oder schreiben mit Dateien.

Ein schönes Beispiel ist das handle auf die geöffnete Datei. Das ist quasi ein Ankerpunkt über den man die gerade mit dieser Prozedur geöffnete Datei erreicht. Auch das Objekt hat so ein handle. Da das aber außerhalb des Objektes niemanden interessiert ( es wird ja nur zur Verwaltung benutzt) ist es in der Oo Variante gar nicht zu sehen. Schaut man sich das Objekt genauer an, wird man aber eine interne Variable handle finden.

Probier es einfach aus und fang mit irgendwas an! Du wolltest Cocoa nutzen, dann ist Objective-C das richtige für Dich! Java ist die klassische Schulmethode um eine OO-Sprache zu lernen. Unkomplizierter für den Anfang ist sicher eine OO-Skriptsprache. Python oder Ruby sind da pot. Vertreter. Wichtig ist das Du Dir eine Sprache aussuchst und erstmal intensiv übst! Welche ist dabei fast egal. Wenn Cocoa Deine Motivation ist, dann starte mit XCode und Objective-C; Du wirst dabei eine der dynamischsten und effektivsten Formen von OO kennenlernen. Java ist da in einigen Dingen starrer, ob das Vor- oder Nachteil beim lernen ist muß jeder selbst entscheiden.
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten