Methoden, Klassen, usw.

[doeme89]

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]

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.

 

[Skeeve]

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]

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]

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]

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]

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.

 

[zeno]

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]

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]

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]

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]

Um kurz abzuschweifen, Nahrung ist wohl ein Interface

 

[doeme89]

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...

 

[doeme89]

Um kurz abzuschweifen, Nahrung ist wohl ein Interface

Genau, wie ist ein Interface definiert?! Es ist gut wenn ich einen gesamten Ueberblick habe, erst dann kann ich vielleicht alles verstehen... :-D

 

[zeno]

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

 

[zeno]

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.

 

[Amin Negm-Awad]

http://www.cocoading.de/Tutorials/Absolute_Beginners_5.html

 

[doeme89]

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

$nahrung wäre in diesem Fall eine Variable, richtig?

 

[doeme89]

http://www.cocoading.de/Tutorials/Absolute_Beginners_5.html

Geniales Tutorial, danke! Bin echt um jedes Tutorial dankbar, damit ich mich vertraut machen kann. Meine Frage hier bezieht sich lediglich auf Fragen was Methoden, Klassen, Objekte etc. sind... Trotzdem danke!

 

[zeno]

$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.