Wann kommt neues OpenGL?

[Plassy]

ne klasse ist doch ein objekt...

mfg
Plassy

[KXII]

...Ob das Überladen von Methoden daugehört, darüber kann man sich streiten

nein darüber kann man sich absolut NICHT streiten. das überladen von funktionen hat überhaupt gar nichts mit objektorientierter programmierung zu tun! ich kann auch nicht nachvollziehen was daran so schwer zu verstehen sein sollte?!?

[DuBi]

Original erstellt von Plassy:
**ne klasse ist doch ein objekt...

mfg
Plassy**

Naja aber daraus bestimmt nun wirklich nicht die 100%ige OOP. wenn nur so 15% höchstens! :p

[KXII]

@helium

ich würde das nicht so streng sehen mit oo=klassenorientierung.

klassen sind auch nur strukturen, und wenn du anstatt "class XYZ" "struct XYZ" benutzt und dann anstatt die funktionen IN die klasse selber schreibst, sie AUSSEN hin schreibst, ist das doch selbe nur in grün; deshalb gleich zu sagen: "man kann auch objektorientiert programmieren ohne "CLASSen" zu benutzen", dann ist das nicht richtig oder anders gesagt, nur die halbe wahrheit.

es gibt halt viele programmierer die das nicht so bis ins detail sehen und deshalb sagen klassen=objekte und deshalb objektorientierte programmierung = programierung mit klassen. lass sie doch einfach.

mit welcher sprache willst denn OHNE strukturen/klassen objekte bilden können und diese instanzieren? denn das bilden einer instanz ist ein wesentliches merkmal oop.

[Cortex85]

warum soll überladen von funktionen nicht zu oop gehören?
ich kenne C nicht so genau, aber soweit ich weiß is das da nicht möglich

[Cortex85]

scheiße, vergesst mein letztes Posting. ich sag jetzt nix mehr dazu ....

[KXII]

ich wollte schon gerade sagen...

das kann nicht dein ernst sein!

[Helium]

ne klasse ist doch ein objekt...

Also das ist ja nun der größte Käse, den ich seit langem gehöt habe. Ich kann auch nicht sagen Holz ist ein Schrank, nur weil mein Schrank aus Holz ist.

Das Objekt entsteht erst bei der Instanzierung der Klasse oder allgemeiner bei der Instanzierung des Typs.

mit welcher sprache willst denn OHNE strukturen/klassen objekte bilden können und diese instanzieren? denn das bilden einer instanz ist ein wesentliches merkmal oop.

Ein Objekt ist bereits eine Instanz und kann nicht mehr instanziert werden.

int x; // jetzt hab ich eine Instanz von int erstellt

struct Foo { ... } y; // jetzt hab ich ne Instanz von Foo erstellt.

Ich sehe sofort, das das Instanzieren eines Typs absolut OOP-Typisch ist, da man weder in funktionalen noch struktorierten Sprachen Variablen verwendent. Denk darüber bitte nochmal nach. Das stimmt nämlich nicht so ganz.

Der Unterschied leigt in folgendem:

if (monster_x == held_x && monster_y == held_y) {
   held_leben = 0;
   spiel_beenden();
}

Nun erstelle ich doch mal schnell ein paar Klassen und denke ich könnte nun OO proggen.

if (monster.x == held.x && monster.y == held.y) {
   held.leben = 0;
   spiel_beenden();
}

Und? Ist das OO? nicht wirklich.

Versuchen wirs nochmal (natürlich verwenden wir wieder Klassen, aber etwas anders):

if (monster.faeng(held)) {
   held.stirb();
   spiel_beenden();
}

Und tada. Selbst jemand, der nicht Progrmmieren, kann mit dem unteren fast was anfangen, wärend das obere eher nach Mathe aussieht.

[Bashar]

In Smalltalk und CLOS sind Klassen auch Objekte.

> (defclass foo () ())
#<Standard-Class FOO #xFFAAF0>

> (type-of (find-class 'foo))
STANDARD-CLASS

[KXII]

@helium

...Ein Objekt ist bereits eine Instanz und kann nicht mehr instanziert werden

also ehrlich, glaubst du wirklich das ich das nicht wüsste??? !

das ist eine sehr einfache und eingeengte sicht von dir, die auch sehr oft von anfängern gebraucht wird (ich hoffe du bist keiner). man sollte das nicht so "streng" sehen. ein objekt ist ein abtraktes gebilde im allgemeinen sinne; und ein instaziertes gebilde kann man auch als objekt bezeichnen, es ist aber nicht zwingend! warauf es ankommt ist zu unterscheiden zwischen der definition eines objektes und der instanzierung eines objektes. wie man diese zwei dinge genau bezeichnet ist nicht relevant. wichtig ist nur das andere wissen was gemeint ist. ich würde niemandem etwas vorwerfen, wenn er das nicht 100% korrekt ausdrückt. mann muss nicht unbedingt zu einem instanzierten "ding" objekt sagen. das ist das selbe, wie wenn man zu funktionen methoden sagen soll. das ist doch blödsinn sich auf solche kleinigkeiten zu beschränken.

du hast geschrieben:

**```cpp
Ich sehe sofort, das das Instanzieren eines Typs absolut OOP-Typisch ist, da

man weder in funktionalen noch struktorierten Sprachen Variablen verwendent.

Denk darüber bitte nochmal nach. Das stimmt nämlich nicht so ganz.

Der Unterschied leigt in folgendem:

if (monster_x == held_x && monster_y == held_y) {
held_leben = 0;
spiel_beenden();
}
Nun erstelle ich doch mal schnell ein paar Klassen und denke ich könnte nun OO proggen.

if (monster.x == held.x && monster.y == held.y) {
held.leben = 0;
spiel_beenden();
}
Und? Ist das OO? nicht wirklich.

Versuchen wirs nochmal (natürlich verwenden wir wieder Klassen, aber etwas anders):

if (monster.faeng(held)) {
held.stirb();
spiel_beenden();
}
Und tada. Selbst jemand, der nicht Progrmmieren, kann mit dem unteren fast was anfangen, wärend das obere eher nach Mathe aussieht.

wenn nur das letzte beispiel für dich OOte programmierung ist, ... naja ... ich hoffe es nicht!  

ich sehe das alles aus einer ganz anderen und viel abtrakteren perspektive. du beschränkst dich wieder auf kleinigkeiten.  

bei OO geht es doch darum, funktionalität in sinnvolle gruppen zu packen und zwar in einer form, die es erlaubt, instzanzen davon bilden zu können. man beschreibt diese gruppen (oft als klassen bezeichnet) und bildet objekte davon, die eine bestimmte lebenszeit haben. es gibt ein eindeutiges davor ein jetzt und ein danach. das ist im groben alles, und wie man es realisiert ist völlig egal. wichtig ist, das man von globalen variablen/objekte wegkommt, die IMMER existieren und nur EIN mal. man könnte es auch als individualisierung bezeichnen.  

der unterschied von  

held_leben = 0;  

und  

"held.leben = 0;"  

und  

"held.stirb();"  

liegt doch nur in der schreibweise.  

die FUNKTIONALITÄT die dahinter steckt ist in allen fällen die selbe. natürlich ist die dritte variante etwas besser gekapselt (das liegt aber nur an c/c++), weil man eine funktion aufruft und man dadurch eine INDIREKTE wertezuweisung ermöglicht, aber das ist doch absolut programmiersprachenabhängig oder anders gesagt designabhängig. man könnte genausogut der instanz "leben" von "held" einen zuweisungsoperator hinzufügen, der nichts anderes macht als eine funktion aufzurufen, die den wert dann indirekt zuweist. das ist dann das selbe (optisch gesehen) wie beim dritten beispiel. oder mann könnte es auch ganz anders machen; es gibt unendlich viele möglichkeiten um diese funktionalität zu realisieren und darzustellen.  

(ganz krass gesagt, man müsste es noch nicht einmal optisch darstellen. mann könnte es auch akustisch machen, mit einer sprache - einen entsprechenden computer und software vorausgesetzt. wäre das dann für dich NICHT mehr OO nur weil man die funktion nicht mehr sehen kann, und sie dadurch natürlich nicht mehr das aussehen wie in beispiel 3 hat?)  

ein einfacherer weg wäre es per "drag and drop" zu machen. das wäre auch OO, auch wenn nirgend steht "abc=blabla;" oder "abc(blabla)" oder sonstwas.  

[ Dieser Beitrag wurde am 27.06.2003 um 22:14 Uhr von **KXII** editiert. ]

[Helium]

OK, verdeutliche ich es etwas. ERsetze den zweiten Teil meines Beispiels durch folgendes. Der Text bleibt der selbe:

if (monster.get_x() == held.get_x() && monster.get_y() == held.get_y()) {
   held.set_leben(0);
   spiel_beenden();
}

Aussage von mir ist immer noch die selbe: Das ist nicht OOP. Das ist pseudogekapsele, das bis auf die Tatsache, das es mehr schreibarbeit ist nichts ändert. Es ist aber schonmal ein großer schritt, da das direkte Setzen der Position verhindert wird, da kein set_x bzw, set_y existiert.

bei OO geht es doch darum, funktionalität in sinnvolle gruppen zu packen und zwar in einer form, die es erlaubt, instzanzen davon bilden zu können. man beschreibt diese gruppen (oft als klassen bezeichnet) und bildet objekte davon, die eine bestimmte lebenszeit haben. es gibt ein eindeutiges davor ein jetzt und ein danach. das ist im groben alles, und wie man es realisiert ist völlig egal.

Man bezeichnet diese "Gruppen" immer als Klassen. Und jede Variable in jeder Sprache hat irgendeine Zeit wärend der sie existiert. Da hat nix mit OO zu tun.

wichtig ist, das man von globalen variablen/objekte wegkommt, die IMMER existieren und nur EIN mal. man könnte es auch als individualisierung bezeichnen.

Ach und bei der strukturierten. Ja aber das war in der struktorierten programmierung doch genauso. Man versucht alle Variablen lokal in Funktionen anzulegen. Bei manchen ging das nicht. die wurden dann global. Jetzt packst du Sie als statisches Element in eine Klasse oder bstelst ein Singleton drumherum. Technisch gesehen ist das doch das selbe.

der unterschied von

held_leben = 0;

und

"held.leben = 0;"

und

"held.stirb();"

liegt doch nur in der schreibweise.

Nein. Das hast du eben nicht verstanden. Die Schreibweise ist völlig egal. Es geht einzig und allein um die Semantik.

[KXII]

du hast geschrieben:

"

held_leben = 0;

und

"held.leben = 0;"

und

"held.stirb();"

liegt doch nur in der schreibweise.

Nein. Das hast du eben nicht verstanden. Die Schreibweise ist völlig egal. Es
geht einzig und allein um die Semantik.

"

du beschränkst wieder OO-programmierung auf kleinigkeiten. die semantik ist in jeder sprache unterschiedlich und die syntax ist vollkommen irrelevant. es kommt bei oo programmierung nicht darauf an, wie man die funktionalität hinschreibt, oder wie das, was hingeschrieben wurde zu deuten ist. ob man "stirb()" schreibt oder "leben=0", es hat keinen einfluss darauf, ob man nun oo programmiert oder nicht, denn sowas ist in einer strukturierten sprache möglch, oder auch in einer oo oder auch selbst in assembler (wie auch immer man diese sprachtyp bezeichnet). mann kann mit assembler eine funktion schreiben die "stirb" heisst, man kann aber auch eine funktion schreiben die "setleben" heisst, und nur weil man "stirb" benutzt heisst das noch lange nicht das die eigentliche programmierweise des ganzen programms objektorientiert ist. es kommt auf die relativen beziehungen von code und daten an, und wenn diese so angeordnet sind, das sie gruppen bilden, und funktionalität kapseln, dann spricht man von einer objekt-orientierten weise, eben weil man "objekte" als sortierkriterium genommen hat und nicht die reine strukturierung. man kann ja schliesslich auch mit assembler oo programmieren, nur man sieht das nicht so deutlich wie in hochsprachen. es mag zwar sein, das ein "stirb" schöner aussieht und in bezug auf die reale welt besser zu verstehen ist, es hat aber keinen einfluss auf die art der programmierweise. man darf oo auch nicht so "humanisiert" betrachten und alles was man programmiert aus unserer realen welt ableiten. das macht vielleicht oft sinn, es ist aber nicht immer möglich und ist auch nicht zwingend nur damit man oo programmiert.

ich sehe es so, und ich kann auch nicht erkennen wo mein denkfehler liegen sollte. falls die klassische informatik objektorientierung anders definiert hat, dann wird es halt zeit für eine neue definition. da bin ich mir sicher. ich kann und will mich auf jeden fall nicht an die alten, klassischen definitionen halten!

deshalb würde ich sagen: jedem seine meinung!

[Killing me Softly]

In der guten alten prozeduralen Zeit gab es auf der einen Seite die dummen Daten und auf der anderen Seite die schlauen Funktionen, die mit den Daten irgendetwas gemacht haben. Viele sehen in der OO nix weiter, als eine Möglichkeit, besagte Daten und Funktionen in Gruppen zu ordnen. Objektorientiertheit hat aber nix mit der sinnvollen Gruppierung von Funktionen und Variablen zu tun.
Ein Objekt hat keine Variablen und Funktionen sondern es hat Eigenschaften und besitzt ein Verhalten. Rein technisch gesehen ist das zwar das gleiche, vom gedanklichen Ansatz aber zwei vollkommen verschiedene Dinge.
Ob ich nun 'held.leben = 0;' oder 'held.set_leben(0);' schreibe, ist vollkommen Banane. In beiden Fällen setzte ich eine Eigenschaft des Objektes. held.sterben() ist allerdings ein Verhalten und es ist Sache des Objektes und nicht des Aufrufers, welche Auswirkungen dieses Verhalten hat. Im einfachsten Falle fällt unser Held tot um. Genauso gut könnte er aber auch zum Zombie mutieren. Das Verhalten kann auch von Objekt zu Objekt unterschiedlich sein.

Für alle, die zwischen 'held.leben = 0;' und 'held.sirb()' nur eine unterschiedliche Schreibweise erkennen empfehle ich mal die Lektüre "Objektorientierte Programmierung von Peter Coad, Jill Nicola"

[Sgt. Nukem]

Original erstellt von <Killing me Softly>:
Ob ich nun 'held.leben = 0;' oder 'held.set_leben(0);' schreibe, ist vollkommen Banane. In beiden Fällen setzte ich eine Eigenschaft des Objektes. held.sterben() ist allerdings ein Verhalten und es ist Sache des Objektes und nicht des Aufrufers, welche Auswirkungen dieses Verhalten hat. Im einfachsten Falle fällt unser Held tot um. Genauso gut könnte er aber auch zum Zombie mutieren. Das Verhalten kann auch von Objekt zu Objekt unterschiedlich sein.

Gut. Aber das Objekt könnte ja bei seiner Instanziierung auch einen eigenen Thread aufgemacht haben, und damit die ganze Zeit checken, ob leben == 0 ist, und wenn ja, DANN zu einem Zombie mutieren, oder einem Werwolf, oder Pamela Anderson...!

[KXII]

@unregistrierter

lies du deine lektüren. ich benutze mein gehirn.

[quadratwurzelsalat]

helium hat recht.

ich habs gerade mal durchgerechnet!!!

[Sgt. Nukem]

Muahahahahaha!! :p

[Helium]

<Killing me Softly> hat die ganz offensichtlich die objektorientierte Programmierung an sich verstanden und weis deren Vorteile zu nutzen, wärend KXII OO nur als eine Art Sprachfeature sieht und im Grunde nix damit anfangen kann. Das heißt natürlich nicht, dass KXII schlechtere Programme schreibt, sondern nur, dass er Sie auf eine aus heutiger sicht leicht veralteten weise schreibt. Aber das soll uns nicht weiter stören.
Und wenn wir jetzt nicht wieder zum Originalthema zurückfinden sollte das Thema bitte vom Moderator geschlossen werden.

[KXII]

@helium

das ist eindeutig eine beleidigung.

wenn hier jemand nicht versteht was objekt-ORIENTIERT heisst, dann du. und ich kann sehr wohl was damit anfangen. und ich glaube auch nicht dass ich meine programme auf eine veraltete weise schreibe. ich habe mindestens 10 argumente warum deine version schwachsinnig und falsch ist. ich habe aber keine lust sie dir darzustellen.

um es auf den punkt zu bringen:

meine darstellung bezieht sich auf OO im ALLGEMEINEN sinne. deine darstellung bezieht sich nur auf einen ganz, ganz kleinen bereich, der oo programmierung zu mehr ausdruck verhelfen KANN, aber absolut nichts mit dem GRUNDKONZEPT zu tun hat. oder willst du etwa sagen, das wenn man auch nur eine einzige funktion hat, die einen parameter hat, man nicht mehr oo programmiert? was ist denn wenn es ein onjekt gibt, das so etwas wie "stirb()" gar nicht kennt, oder bei dem nur ein "stirn(3)" sinn macht. dann wäre ja nach deiner defnition dieses objekt nicht mehr oo programmiert. aber das ist doch totaler schwachsinn. bevor du hier nochmal postest, dann bring erst mal deine definition von ALLGEMEINER oop und schwafel hier keinen scheiss, der obendrein auch noch falsch ist!

[kubikwurzelsuppe]

stimmt. KXII hat recht. oop geht viel weiter als nur auf die schreibweise von funktionen beschränkt. eine solche schreibweise macht oop deutlicher, aber es ist kein konstituierendes element. ich glaube auch das das beispiel von helium zu einfach gewählt ist. das was KXII gesagt hat passt ganz gut. was passiert denn wenn das objekt keine funktion "stirb" hat, sondern nur eine funktion "stirb(long,long,float)" einfach weil das so ist, und es anders keinen sinn macht. ist es dann nicht mehr objektorientiert programmiert, nur weil die funktion andere parameter hat? wo liegt da genau die grenze? gibt es da überhaupt eine grenze? und wer legt sie fest? wenn jemand das sterben von objekten anders sieht oder anders definiert, dann soll er es auch so programmieren! ist es dann aber nicht mehr objektorientiert programmiert nur weil er es anders gemacht hat als mit deiner vsersion helium? ich glaube wenn man so "eng" versucht objektorientierteprogrammierung zu beschreiben, dann wird das ganze sehr diffus!