Methoden, Klassen, usw.

doeme89

Pomme Miel
Registriert
27.12.06
Beiträge
1.477
Hallo Profis! ;)

Ich habe mir die Cocoa-Tutorials aut AT bereits angeschaut, und bin begeistert! Dort wird alles ziemlich einfach beschrieben.

Blöderweise stosse ich beim Programmieren lernen immer wieder auf Hindernisse, in jeder Sprache die ich bereits versucht habe. Cocoa ist übrigens die erste mit UI die ich (versuche) zu lernen. Jetzt aber zur eigenlichen Frage: Kann mit jemand auf einfachste Weise versuchen zu erklären, was genau Methoden, Klassen, etc. sind? Variablen sind mir völlig klar, das andere Zeugs sitzt einfach noch nicht ganz fest...

Gruss, doeme
 

zeno

Lane's Prinz Albert
Registriert
05.11.05
Beiträge
4.894
Ich versuchs mal ganz knapp:
Stell dir zum Beispiel mal vor, wir wollten nen Hund programmieren. Damit alles was zum Hund gehört unter einem Hut ist, packen wir den in eine Klasse. Wir haben also ne Klasse Hund{} und so ein Hund der kann zum Beispiel essen, bellen, etc etc.. (vgl. hiermit). Das müssen wir dem beibringen.. also sagen wir was der Hund so machen muss um zu essen und damit das alles wieder schön gekappselt ist packen wir das in eine Methode essen().

Dann haben wir quasi

Hund{
int magenvoll = 0;
essen() {
$magenvoll++;
}
}
Wenn du dich schonmal in PHP versuch hast, Methoden sind das was in PHP quasi Funktionen sind. Nur das sie zu einer Klasse gehören und nicht einfach so vorkommen.
 
  • Like
Reaktionen: Bier

Skeeve

Pomme d'or
Registriert
26.10.05
Beiträge
3.120
Ich habe das OO-Programmieren auch noch nicht so drin. Mir stellt sich das so dar:
Klassen sind "Baupläne" für Objekte. Sozusagen die Variablentypen, nur mächtiger.
Objekte/Instanzen sind Dinge, die Speicherplatz belegen und Daten enthalten.
Methoden sind Funktionen einer Klasse die auf Objekte dieser Klasse angewendet werden können.
 

doeme89

Pomme Miel
Registriert
27.12.06
Beiträge
1.477
Ich versuchs mal ganz knapp:
Stell dir zum Beispiel mal vor, wir wollten nen Hund programmieren. Damit alles was zum Hund gehört unter einem Hut ist, packen wir den in eine Klasse. Wir haben also ne Klasse Hund{} und so ein Hund der kann zum Beispiel essen, bellen, etc etc.. (vgl. hiermit). Das müssen wir dem beibringen.. also sagen wir was der Hund so machen muss um zu essen und damit das alles wieder schön gekappselt ist packen wir das in eine Methode essen().
Danke für die super Beschreibung, das Flussdiagramm am anderen Ende des Links ist auch super als Gedankenstütze! Trotzdem wirft sich nun eine neue (weiterführende) Frage auf: Könnte man anstatt gleich eine Methode "essen" zu machen auch zuerst eine 'Unterklasse' "nahrung{}" machen, und darin 2 Methoden (eine "essen" und eine "trinken")? Nach meiner Logik müsste das gehen, will mich aber nur versichern, damit keine Zweifel mehr bleiben...
 

hanebambel

Becks Apfel (Emstaler Champagner)
Registriert
31.08.04
Beiträge
333
Danke für die super Beschreibung, das Flussdiagramm am anderen Ende des Links ist auch super als Gedankenstütze! Trotzdem wirft sich nun eine neue (weiterführende) Frage auf: Könnte man anstatt gleich eine Methode "essen" zu machen auch zuerst eine 'Unterklasse' "nahrung{}" machen, und darin 2 Methoden (eine "essen" und eine "trinken")? Nach meiner Logik müsste das gehen, will mich aber nur versichern, damit keine Zweifel mehr bleiben...

eher nicht, da nahrung ja nicht essen kann, sondern nur gegessen werden kann.
Man könnte aber, wenn man wissen will, wieviel der Hund gegessen hat, der Methode Essen ein Objekt vom Typ Nahrung mitgeben...

Ansonsten is dieses Buch echt gut: http://www.galileocomputing.de/openbook/oo/

Cu Jan ;)
 

Alferd

Auralia
Registriert
19.05.05
Beiträge
202
Könnte man anstatt gleich eine Methode "essen" zu machen auch zuerst eine 'Unterklasse' "nahrung{}" machen

Nein, eine Unterklasse von Hund wäre zum Beispiel Dackel. Da sieht man auch schön die Vererbung. Ein Dackel ist ein Hund, ein Pudel ist ein Hund. Beide 'erben' von der Oberklasse Hund zum Beispiel die Methode 'essen()'. Ein Dackel wird manchmal aber zum Beispiel bei der Jagd eingesetzt und könnte dann eine Methode 'jagen()' haben, die ein Pudel nicht unbedingt haben muss.

Natürlich kannst Du aber die Methoden essen() und trinken() zu einer Methode nahrungAufnehmen() zusammenfassen, wenn sich das in Deinem Modell anbietet.
 

Peter Maurer

Pommerscher Krummstiel
Registriert
16.03.04
Beiträge
3.077
Essen waere eine andere Klasse, die Du in Objective-C dann z.B. so ansprechen koenntest:

[myHund nimmNahrungAuf: [myNahrung getraenk]]

Unterklassen sind eher Spezialfaelle ihrer uebergeordneten Klassen, so koennte z.B. Schaferhund eine Hund-Unterklasse sein, die alle Methoden und Variablen von Hund erbt, zusaetzlich aber noch die Variable anzahlDerSchafe und die Methode haltDieSchafeZusammen definiert.

EDIT: Ich bin ja sooo langsam. :D
 

zeno

Lane's Prinz Albert
Registriert
05.11.05
Beiträge
4.894
Magst du essen() und trinken() auslagern damit es "sauberer" aussieht oder weil du schon in die Zukunft denkst und überlegst nach dem Hund{} eine Ente{} zu programmieren?
 

doeme89

Pomme Miel
Registriert
27.12.06
Beiträge
1.477
eher nicht, da nahrung ja nicht essen kann, sondern nur gegessen werden kann.
Man könnte aber, wenn man wissen will, wieviel der Hund gegessen hat, der Methode Essen ein Objekt vom Typ Nahrung mitgeben...
Ach so, klingt logisch! Würde man einen Tagesablauf eines Menschen programmieren, der 3-Mal täglich Salat isst, hätte die oberste Klasse die Methode salat(). Am Abend isst er aber dann noch zusätzlich Pizza, d.H. es müsst eine Unterklasse 'Abendessen()' erstellt werden mit der Methode pizza(). Die Mehode salat() wird dann ja vererbt, richtig?

Nein, eine Unterklasse von Hund wäre zum Beispiel Dackel. Da sieht man auch schön die Vererbung. Ein Dackel ist ein Hund, ein Pudel ist ein Hund. Beide 'erben' von der Oberklasse Hund zum Beispiel die Methode 'essen()'. Ein Dackel wird manchmal aber zum Beispiel bei der Jagd eingesetzt und könnte dann eine Methode 'jagen()' haben, die ein Pudel nicht unbedingt haben muss.

Natürlich kannst Du aber die Methoden essen() und trinken() zu einer Methode nahrungAufnehmen() zusammenfassen, wenn sich das in Deinem Modell anbietet.
Alles klar! Man beschreibt also zuerst die rudimentären Funktionen (bzw. Methoden) eines Hundes, und fügt dann in den Unterklassen die rassenspezifischen Methoden hinzu...
 

doeme89

Pomme Miel
Registriert
27.12.06
Beiträge
1.477
Magst du essen() und trinken() auslagern damit es "sauberer" aussieht oder weil du schon in die Zukunft denkst und überlegst nach dem Hund{} eine Ente{} zu programmieren?
Klingt beides logisch. Ich dachte aber eher damit es sauberer aussieht...
 

hanebambel

Becks Apfel (Emstaler Champagner)
Registriert
31.08.04
Beiträge
333
Ach so, klingt logisch! Würde man einen Tagesablauf eines Menschen programmieren, der 3-Mal täglich Salat isst, hätte die oberste Klasse die Methode salat(). Am Abend isst er aber dann noch zusätzlich Pizza, d.H. es müsst eine Unterklasse 'Abendessen()' erstellt werden mit der Methode pizza(). Die Mehode salat() wird dann ja vererbt, richtig?

Nein, Pizza und Salat wären unterklassen von Nahrung und keine Methoden. Methoden sind immer Aktionen, die ein Objekt ausüben kann. Also hat der Hund (das Objekt) eine Methode essen (weil er das machen kann).

CU Jan ;)
 

zeno

Lane's Prinz Albert
Registriert
05.11.05
Beiträge
4.894
Um kurz abzuschweifen, Nahrung ist wohl ein Interface ;)
 

doeme89

Pomme Miel
Registriert
27.12.06
Beiträge
1.477
Nein, Pizza und Salat wären unterklassen von Nahrung und keine Methoden. Methoden sind immer Aktionen, die ein Objekt ausüben kann. Also hat der Hund (das Objekt) eine Methode essen (weil er das machen kann).

CU Jan ;)
In demfall können (Unter-)klassen nicht nur in Klassen vorkommen sondern auch in Methoden?! Ich verstehe das so, wenn ja essen eine Methode ist...
 

zeno

Lane's Prinz Albert
Registriert
05.11.05
Beiträge
4.894
In demfall können (Unter-)klassen nicht nur in Klassen vorkommen sondern auch in Methoden?! Ich verstehe das so, wenn ja essen eine Methode ist...

Also drin vorkommen ist falsch, aber du kannst sie Nutzen. Wenn du jetzt z.B die Methoden essen(nahrung $nahrung) hättest, kann $nahrung auch ne Pizza sein. Oder im Rumpf der Methode dann selbst, wenn du da z.B. ein zufälliges Nahrungsmittel auswählst.


P.S. ich wervwende für die ganzen Bespiele mal Pseudocode, weil ich kein Cocoa/Objetiv-C kann :oops:
 

zeno

Lane's Prinz Albert
Registriert
05.11.05
Beiträge
4.894
Genau, wie ist ein Interface definiert?! Es ist gut wenn ich einen gesamten Ueberblick habe, erst dann kann ich vielleicht alles verstehen... :-D

Mh wie erklär ich das jetzt. Ein Interface ist sowas wie ein Generalbauplan für eine Klasse.. Das Interface sagt das die und die Methoden vorkommen müssen, um beim Tieren zu bleiben z.B. essen(), lautgeben(), schlafen(). Mehr sagt gibt das Interface nicht vor, wie du jetzt als Erschaffer eines Tieres das essen bewerkstelligst oder ihm das lautgeben beibringst, das ist dem Interface egal, solang die Methoden stimmen.
 

doeme89

Pomme Miel
Registriert
27.12.06
Beiträge
1.477
Also drin vorkommen ist falsch, aber du kannst sie Nutzen. Wenn du jetzt z.B die Methoden essen(nahrung $nahrung) hättest, kann $nahrung auch ne Pizza sein. Oder im Rumpf der Methode dann selbst, wenn du da z.B. ein zufälliges Nahrungsmittel auswählst.


P.S. ich wervwende für die ganzen Bespiele mal Pseudocode, weil ich kein Cocoa/Objetiv-C kann :oops:
$nahrung wäre in diesem Fall eine Variable, richtig?
 

zeno

Lane's Prinz Albert
Registriert
05.11.05
Beiträge
4.894
$nahrung wäre in diesem Fall eine Variable, richtig?

Genau. Und zwar vom Typ Nahrung.. also d.h. es gibt auch ne Klasse Nahrung die irgendwo in deinem Projekt zu einem Objekt belebt worden ist. Wie Skeeve schon schrieb, eine Klasse ist ein Bauplan und ein Objekt ist der umgesetzte Bauplan.